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: http://pastie.org/private/227rccbneipj3wf8cdtnq 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: http://pastie.org/private/ldav9oe0cdayk2cxb8n4xg added your select, can’t reproduce
Dammann: SuperQ: http://sprunge.us/YjBU
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: http://sprunge.us/MXRH
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.
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.