相关参数
binlog-checksum={NONE|CRC32} — NONE表示binlog 中的事件里面不记录checksum值，保持与老版本兼容；而CRC32则在事件中加入用来确认事件是否正常的checksum值。
master-verify-checksum={0|1} – 该参数用来判断主库写入到binlog中的事件是否正常，Dump Thread用来将主库更新事件读出发给从库的I/O Thread，当它读出事件时会进行checksum校验，对于复制来说这此判断不太需要，只需要在复制端判读出过来的事件事件是否正常即可，默认设置为0关闭checksum检查；另外，当我们执行命令SHOW BINLOG EVENTS的时候也会触发checksum校验。
slave-sql-verify-checksum={0|1} – 该参数用来判断从库SQL Thread从relay log中读出的事件是否正常，默认设置为1。
Checksum校验过程
从上面的复制内部结构图中我们可以看到，一个复制过程一共会经历5个步骤，由于硬件问题（harddisk,memory）、软件BUG、网络问题（传输过程中的意外）等各种问题的存在，为了保证binlog中的一个事件从写入到被复制到从库上被应用，整个过程中前后保持一致，那么就需要在5个步骤中完成checksum校验。
步骤（一）：当主库记录binlog时，将events中加入checksum标记；
步骤（二）：当Dump Thread读取events时，进行checksum校验，通常并不需要校验；
步骤（三）：该阶段也没有必要进行checksum校验，I/O Thread对于从Dump Thread复制过来的events是否正常的判断，可在写入relay log时再去校验，复制过来的events也都带有checksum标记；
步骤（四）：当I/O Thread写入relay log时，完成对复制过来的events的checksum校验；
步骤（五）：当SQL Thread应用日志前，会在读取events时进行checksum校验。
为了保证复制过程中事件的正确性，在数据写入复制的过程中做了全程跟踪，以便做到故障发生，我们可以很清楚知道问题所在，但这势必一定会带来性能上的penalty，而处于pragmatic的原因checksum尽可能只在必要适当的位置发生。
TAKEAWAY
命令mysqlbinlog的新增选项--verify-binlog-checksum可以输出CRC32相关的一些信息，比如：32位的checksum值，当binlog中有corrupted events时，在对应事件的位置处会有ERROR提示。
深入阅读
http://mysqlmusings.blogspot.com/2011/04/replication-event-checksum.html
http://dev.mysql.com/worklog/task/?id=2540