当前位置:Gxlcms > mysql > 比较MySQL5.6与前版的同步协议

比较MySQL5.6与前版的同步协议

时间:2021-07-01 10:21:17 帮助过:25人阅读

前面几节介绍了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


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

人气教程排行