评论

收藏

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

数据库 数据库 发布于:2021-07-04 10:59 | 阅读数:340 | 评论:0

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


  
关注下面的标签,发现更多相似文章