Comments on: Binary log checksums in MySQL 5.6

By: James Day

James Day — Thu, 04 Oct 2012 09:57:17 +0000

Baron, yes, they will help with that. Partly by increasing the confidence that it’s really a bug and not bad luck and partly because verifying the checksum can be enabled at different places to narrow down the location of the problem.

James Day, MySQL Senior Principal Support Engineer, Oracle

By: Mats Kindahl

Mats Kindahl — Wed, 03 Oct 2012 11:51:01 +0000

I keep running up against this confusion as well where people mix up the purpose of each. I have therefore started to refer to checksums used in the way pt-table-checksum uses it as “digest” (e.g., as in “Message Digest 5″) or “hash” (e.g., as in “Secure Hash Algorithm 1″). The term “checksums” have a very clear meaning in data communication literature where it is used to check absence of errors that have occured during transfer or storage. Might help avoiding some confusion on your behalf as well.

By: XL

XL — Tue, 02 Oct 2012 09:56:48 +0000

Every once in a while we have seen replication glitches at customers. The suspect was a faulty network driver where the (offloaded) checksumming for ethernet/ip/tcp was broken. This theory was backed by the fact that enabling SSL for the replication channel fixed the problem (SSL uses its own, stronger checksum).

With SBR, such glitches typically manifested in broken SQL syntax and forced the SQL thread to stop. So they were at least detectable.

With RBR however, even a garbled binlog event looks valid. This increased the pressure to come up with an integrated strong checksum. It’s nice to see it happen.

By: Xaprb

Xaprb — Mon, 01 Oct 2012 23:23:54 +0000

The checksums should also help catch and avoid similar bugs in the future, as long as they don’t originate on the master side before the checksum is computed.

By: James Day

James Day — Mon, 01 Oct 2012 03:58:16 +0000

For those of us who were around before 2009 and remember seeing fairly common relay log corruption, the critical fix was http://bugs.mysql.com/bug.php?id=26489 in 5.0.56 and 5.1.24. The problem turned out to be the master resending partial events after a timeout. That and two smaller fixes hugely reduced the incidence of relay log corruption reports. They are now rare for people using 2009 and later versions of MySQL.

The checksums are good additional protection because errors do still occasionally happen on the wire or disks.

Views are my own, for an official Oracle view, seek a PR person.

James Day, MySQL Senior Principal Support Engineer, Oracle.