您好,欢迎访问一九零五行业门户网

比较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 {4table id } else {6table id }2flags if version == 2 {2extra-data-lengthstring.var_lenextra-data }body:lenenc_intnumber of columnsstring.var_lencolumns-present-bitmap1, length: (num of columns+7)/8 if update_rows_eventv1 or v2 {string.var_lencolumns-present-bitmap2, length: (num of columns+7)/8 }rows:string.var_lennul-bitmap, length (bits set in 'columns-present-bitmap1'+7)/8string.var_lenvalue of each field as defined in table-map if update_rows_eventv1 or v2 {string.var_lennul-bitmap, length (bits set in 'columns-present-bitmap2'+7)/8string.var_lenvalue of each field as defined in table-map } ... repeat rows until event-end
本文出自 “小强技术博客” 博客,请务必保留此出处
其它类似信息

推荐信息