Tag Info

New answers tagged

3

We were seeing the same issue on two servers on versions 5.6.12 and 5.6.16 running on Windows, with a pair of slaves each. We were stumped, like you, for almost two months. Solution: set global binlog_order_commits = 0; See https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_order_commits for details of the variable. ...


3

load spikes to 400% That probably means that you are CPU-bound and not I/O-bound. And hence, you have plenty of RAM, but the queries are inefficient. [!!] Query cache prunes per day: 4351 In most production systems, the write traffic is so high that the Query cache should be turned off. There are other metrics to further demonstrate that. ...


1

Your performance issues can likely be solved by fixing the second issue: joins without indexes. If you are making joins against non-indexed columns in your query, it will have to do a lot more work to determine 1) if there are matches and 2) what matches. You can use the log option log-queries-not-using-indexes in your MySQL configuration (my.cnf) to log ...


0

Plan A: Use INSERT IGNORE in your batched inserts. That way the dup keys do not cause trouble. Plan B: Insert into a table with INDEX, not UNIQUE. Then you can investigate the duplicates before deciding what to do with them. You understand that CHAR(15) utf8 occupies 45 bytes always? Perhaps VARCHAR(15) would be better? (Please don't quote the ...


0

There is no guarantee that the valueaaaaaaaaaaaaaaa-11111 in the message [23000][1062] Duplicate entry 'aaaaaaaaaaaaaaa-11111' for key 'mykey' is the value that actually causes the violation. Seems to be a bug in MariaDB and evtl. in MySQL.



Top 50 recent answers are included