比较MySQL 5.6与前版的同步协议

前面几节介绍了MySQL的基本同步协议，4.1是个重要的转折，新版的在协议包数据格式方面，一般要设置CLIENT_PROTOCOL_41，并且按照设置此标志位的格式序列化与反序

前面几节介绍了MySQL的基本同步协议，4.1是个重要的转折，新版的在协议包数据格式方面，一般要设置CLIENT_PROTOCOL_41，并且按照设置此标志位的格式序列化与反序列化。但是4.1毕竟比较旧了，我们这次关注5.6带来的变化。

1. 对事件的完整性校验

5.6默认是对事件做完整性校验的，即每个事件包的最后4个字节是校验和，校验和作为事件体的一部分，算在事件长度中。并且没有在之前的包格式中定义出来，需要额外加进去。校验和计算方法只采用CRC32，不排除在以后的版本中使用别的算法。

从库需要通知主库“我知道事件的尾部是校验和，并且希望你发送校验和给我”。这个操作需要在发送COM_BINLOG_DUMP命令之前完成，否则服务器发送完一个事件之后（应该是个伪ROTATE事件，并且事件长度不包括校验和的4个字节）立即附带一个ERROR包。文本字段内容是：“Slave can not handle replication events with the checksum that master is configured to log”。

通知方法是：发送一个COM_QUERY命令，内容是“SET @master_binlog_checksum= @@global.binlog_checksum”。在MySQL5.6.14的rpl_slave.cc Line 2154中，，发送过后还发送了第二个COM_QUERY命令，内容是“SELECT @master_binlog_checksum”，查询结果应该是“CRC32”。这说明主库做了CRC校验，并且主库知道从库能够正确的解析完整性校验结果。

2. 新增的事件、标志位与ROW事件格式解析变化

新增事件：HEARTBEAT_EVENT、IGNORABLE_EVENT、ROWS_QUERY_EVENT、WRITE_ROWS_EVENTv2、UPDATE_ROWS_EVENTv2、DELETE_ROWS_EVENTv2、GTID_EVENT、ANONYMOUS_GTID_EVENT、PREVIOUS_GTID_EVENT。

新增标志位：待总结。

ROW格式的三个修改事件（update、write、delete），5.6会选用v2格式。和以前的格式相比，多出了extra_data和extra_data_length两个字段。特殊的，长度字段是2个字节，这两个字节和extra_data的长度一起算到长度字段中。

header: if post_header_len == 6 { 4 table id } else { 6 table id } 2 flags if version == 2 { 2 extra-data-length string.var_len extra-data } body: lenenc_int number of columns string.var_len columns-present-bitmap1, length: (num of columns+7)/8 if UPDATE_ROWS_EVENTv1 or v2 { string.var_len columns-present-bitmap2, length: (num of columns+7)/8 } rows: string.var_len nul-bitmap, length (bits set in 'columns-present-bitmap1'+7)/8 string.var_len value of each field as defined in table-map if UPDATE_ROWS_EVENTv1 or v2 { string.var_len nul-bitmap, length (bits set in 'columns-present-bitmap2'+7)/8 string.var_len value of each field as defined in table-map } ... repeat rows until event-end

本文出自 “小强技术博客” 博客，请务必保留此出处