AllgoodAtTaoti: the short.

Groupe: So for one app using a mysql cluster always starts read queries with BEGIN, so all the read patterns look the same to events_statements_summary_by_digest

Sturch: Kolbe: So yea, not a typical problem :

Segel: SuperQ: so a single connection does “begin; select .; begin; select .” or something?

Zicari: Segel: even a begin ; select * from A ; end will get rolled up in the events statements with begin ; select * from B ; end

Hansel: Segel: When you look at events_statements_summary_by_digest digest_text, you just see BEGIN

Dammann: SuperQ: the entire transaction is recorded as a single row in events_statements_summary_by_digest?

Ailstock: Segel: If you have MySQL 5.6, try “SELECT DIGEST, LEFTDIGEST_TEXT,50 FROM performance_schema.events_statements_summary_by_digest WHERE SCHEMA_NAME NOT IN ‘mysql’, ‘performance_schema’, ‘information_schema'”

Mccrohan: Kolbe: Yes, it seems that way

Mourning: Oh, no, it’s worse than that

Segel: SuperQ: what am i missing?

Jeffus: What’s the best practice for doing change data capture with mysql? specifically on amazon rds?

Dammann: SuperQ: i don’t think that’s right. i certainly don’t see that behavior here.

Segel: SuperQ: added your select, can’t reproduce

Dammann: SuperQ:

Garriepy: Very strange, what mysql version are you using?

Dammann: Me? 5.6.20, as it says in my prompt

Batun: Yea, sorry, I’m blind :

Soop: I’m going to dump some verbose slow query logs, just to see if there’s anything strange for this app

Segel: SuperQ: see how it helps to just ask :

Dammann: SuperQ: yeah, this doesn’t sound so “advanced” to me.

Sharbono: Segel: I asked earlier, nobody responded

Dammann: SuperQ: simple troubleshooting. you claim to see one thing, everyone else demonstrates that you’re wrong, etc. :

Nierenberg: Snoyes: well, i can log in the mailadmin, but i cannot create any mail accounts

Goral: Y can read the database, see the accounts

Macky: But no modify or p***word change

Mcgath: It seems a permissions issue right?

Huewe: The difficulty is I see this consistently across several servers

Kolp: I’m perfectly willing to blame the stupid twitter finagle mysql client my developers use

Segel: Asterismo: connect as the user and issue “show grants;” dont share the p***word hash here

Dammann: SuperQ: “stupid twitter finagle mysql client”?

Dammann: Same behavior in 5.6.26 as in 5.6.20, fwiw:

Gladish: Https://

Dammann: What the hell is finagle?

Hoenig: So I’m having this strange issue. Basically we’re getting a pdo exception details at top of gist which is basically telling me that we’re trying to save an INT of value = 2.14 billion the limit for 32 bit ints in sql. So I’ve deleted the column and recreated it as a float. But we’re still getting pdo exceptions. So I dug into mysql and am getting some weird rounding behavior for field_total_cost_generation_1_value also detailed in the gist.

Toudle: Https://

Dammann: Actually, scratch that, i am not interested enough in the answer for it to be worth anyone explaining it

Brozeski: I enter in a float of 2066929497.9078 valid I believe and end up with a number in the db as 2066930000

Birtwell: Why would it round to the ten thousands place like that

Dammann: AllgoodAtTaoti: is it really a FLOAT column?

Dammann: AllgoodAtTaoti: can you provide SHOW CREATE TABLE output?

Creer: I believe so, the desc of the table indicates it is

Dammann: AllgoodAtTaoti: the short answer is don’t use floats. use DECIMAL if you want to accurately store the number you send.