前面几节介绍了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本文出自 “小强技术博客” 博客，请务必保留此出处
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
769
收藏
