| 00:21.55 | *** join/#utah infobot (ibot@rikers.org) |
| 00:21.55 | *** topic/#utah is Utah-related discussion including user groups | logs @ http://infobot.rikers.org/%23utah/ | See also ##lds | To combat spam, you must register with NickServ if you wish to speak. This may or may not be temporary. |
| 00:21.55 | *** mode/#utah [+o infobot] by ChanServ |
| 03:16.01 | *** join/#utah tiwula (~lane@174-23-75-153.slkc.qwest.net) |
| 04:01.37 | *** join/#utah Bloodythorn (~Bloodytho@c-76-27-46-75.hsd1.ut.comcast.net) |
| 06:26.51 | *** join/#utah tristanbob_h (~Tristan@2602:41:82b1:f800:eda4:d6e5:8ae2:e840) |
| 06:39.41 | klys | ~slashdot |
| 09:11.57 | *** join/#utah ByronJohnson (~bairyn@unaffiliated/bob0) |
| 12:16.39 | *** join/#utah romanovic_ (~romanovic@puritynine.com) |
| 13:02.23 | *** join/#utah emcnabb (emcnabb@nat/redhat/x-hyeozmgctwbdsphl) |
| 14:02.25 | *** join/#utah josephscott (~josephsco@c-174-52-11-31.hsd1.ut.comcast.net) |
| 15:22.16 | *** join/#utah braxtron (~braxtron@216.160.248.178) |
| 15:23.36 | *** join/#utah Migs (~migs@205.122.50.217) |
| 15:23.42 | eightyeight | https://mashable.com/2018/04/30/simone-giertz-brain-tumor-shitty-robots/ |
| 15:49.56 | *** join/#utah tiwula (~lane@70.89.246.241-Busname-UT.hfc.comcastbusiness.net) |
| 16:38.53 | *** join/#utah BLZbubba (~mark@pdpc/supporter/professional/blzbubba) |
| 17:04.40 | programmerq | yeah, I saw that. hoping the best for her. |
| 17:21.11 | jlp_znc | any mysql gurus around here? |
| 17:21.21 | jlp_znc | or do I need to go ask on #mysql? |
| 17:22.24 | jlp_znc | I'm in the process of migrating data from a mysql db in digital ocean to an AWS RDS Aurora instance. unfortunately, the original db had the timezone set to SYSTEM and the system timezone set to America/Denver (why? I don't know.) |
| 17:24.17 | jlp_znc | problem is that, even though I have set the global time zone on the aurora instance to America/Denver, when it tries to do the replication connection (aurora db connecting to source db as slave) the aurora side seems to think it is in UTC while the source side is in America/Denver. this results in all of my timestamp columns in rows that come in via replication being off by six hours. :( |
| 17:25.04 | BigBen212 | can you just run an update after on that column ? |
| 17:25.32 | BigBen212 | and is the target column on your aurora a "timestamp with time zone" type ? |
| 17:25.40 | jlp_znc | ahh, you see, when I initialized the aurora db (from an xtrabackup), all the timestamps came in correctly. it's only timestamps that came in via replication that are the problem. |
| 17:26.02 | jlp_znc | I'm pretty sure the columns are not timestamp with time zone... that would likely have made the problem not happen. |
| 17:26.43 | jlp_znc | what I'd like to do is find a way to have the replication user, when it connects to the source db, to set it's session timezone to UTC. |
| 17:27.04 | jlp_znc | kind of like an initstmt on the connection, but I can't change the way aurora makes the connection so I'd have to do it in config on the source db side. |
| 17:27.23 | jlp_znc | so far, I have an idea for a kludgy solution, but I don't like it. |
| 17:28.12 | jlp_znc | (kludgy solution, write a proxy that sits between aurora and source db and whenever a new connection is made it issues the set session.time_zone variable to UTC before doing anything else) |
| 17:28.37 | BigBen212 | nothing wrong with kludgy if it's a one-time thing |
| 17:29.04 | BigBen212 | but if this is a replication that's supposed on a regular basis rather than a one-time move, then ... not so good |
| 17:29.20 | BigBen212 | +happen |
| 17:29.24 | jlp_znc | no, it's just a one time thing. we are migrating from digital ocean -> AWS |
| 17:29.48 | BigBen212 | does mysql have a copy ? |
| 17:30.01 | jlp_znc | have a copy of ? |
| 17:30.37 | BigBen212 | copy like this: https://www.postgresql.org/docs/9.2/static/sql-copy.html |
| 17:31.17 | jlp_znc | oh, I don't think that would help as I'm depending on the mysql replication mechanism to keep aurora up to date until we cut over. |
| 17:31.37 | BigBen212 | aurora is based on PostgreSQL isn't it? So with that, with the export result from mysql you can import that again |
| 17:31.57 | jlp_znc | there are two underlying engines in aurora, postgresql and mysql. we're (sadly) using the mysql engine. |
| 17:31.59 | BigBen212 | oh, so it's not just a one-time transfer then. I agree, that's not a good solution for that |
| 17:32.48 | jlp_znc | if we were using postgresql, it would not have been a problem as postgresql knows to always use UTC timestamps internally. |
| 17:33.16 | jlp_znc | but changing from mysql to postgresql is not a small project. |
| 17:33.44 | BigBen212 | yup, sucks |
| 17:34.09 | BigBen212 | sorry, my mysql experience isn't all that great. |
| 17:34.31 | jlp_znc | yeah, neither is mine. |
| 17:34.34 | jlp_znc | a real database would be nice. |
| 17:35.13 | jlp_znc | and my google-fu is failing me. I'm finding all kinds of things that let me set it on the connect string with various connection libraries, but of course, I don't have access to that with aurora. |
| 17:51.11 | *** join/#utah braxtron (~braxtron@216.160.248.178) |
| 20:21.32 | *** join/#utah braxtron (~braxtron@216.160.248.178) |
| 20:30.01 | *** join/#utah emcnabb (~emcnabb@hs-nc-1fff767f54-29977-1.tingfiber.com) |
| 21:13.58 | *** join/#utah josephscott (~josephsco@c-174-52-11-31.hsd1.ut.comcast.net) |
| 21:26.48 | *** join/#utah HexaKhan (~HexaKhan_@45-25-108-130.lightspeed.rlghnc.sbcglobal.net) |
| 21:29.21 | *** join/#utah HexaKhan_ (~HexaKhan_@45-25-108-130.lightspeed.rlghnc.sbcglobal.net) |
| 22:46.32 | eightyeight | https://www.zdnet.com/article/github-says-bug-exposed-account-passwords/ |
| 23:05.11 | unum | eightyeight: what are your thoughts on logmein, gotomeeting, teamviewer, etc |
| 23:07.34 | eightyeight | All I know of them is that they're remote access software for troubleshooting. I haven't used them personally. |
| 23:23.33 | jlp_znc | I've used teamviewer and gotomeeting before. They pretty much do the same thing... allow remote control of a machine. I don't have an opinion of one over the other. |
| 23:54.29 | frostyfrog | uses vnc |
| 23:59.33 | jfindlay | ssh tunneling is a necessity if you're using vnc |