#MySql-Binlog协议详解-报文篇

紧接上篇流程篇，本篇主要将binlog的event报文。

##Event报文分层

event报文主要分三层。

(1)MySql报文都有的length-body防粘包结构。

(2)Event Header

(2)Event Body

总体结构如下图所示:

##EventHeader

Event Header结构如下图所示:

(1)前4比特，是当前binlogEvent发生的时间戳

(2)1byte的event类型,详情见github

(3)4byte的serverId,是发送event的主库标识

(4)4byte的event_length,是指包含当前eventHeader的整个body的长度

(5)最后2byte是标志位

解EventHeader报文的代码如下所示:

public void read() {

timestamp = mm.readUB4() * 1000;

eventType = getEventType(mm.read());

serverId = mm.readUB4();

eventLength = mm.readUB4();

nextPosition = mm.readUB4();

flags = mm.readUB2();

}

EventBody

紧接着就是描述EventBody。EventBody根据类型分主要有:

(1)RotateEventData:当MySql的binlog文件从file1滚动到file2的时候会发生此事件。

(2)UpdateRowsEventData:当binlog格式设置的是Row|mixed且Row更新的时候会发生此事件。

(3)QueryEventData:当binlog格式设置的是statement|mixed且做DB有了更新、插入或删除操作的时候会发生时间(例如修改Row,alter表等)。

(4)WriteRowsEventData:当binlog格式设置的是Row|mixed且有insert操作时候，有此事件发生。

(5)余下还有不少event格式，在此就不一一罗列了，具体见github

RotateEventData

(1)8byte的binlogPosition

(2)以0x00结尾的String,表示了当前binlog文件名

###UpdateRowsEventData

(1)byte的tableId,表明唯一一张表

(2)一个复杂的Bit集合，有更新的Row在更新之前的值在下面Row列表中的位置

(3)一个复杂的Bit集合，有更新的Row在更新之后的值在下面Row列表中的位置

(4)一个Row的列表，配合上面两个bitSet使用

具体解析BitSet非常复杂，详情见github

###QueryEventData

(1)4bytes的线程id

(2)4bytes的当前事件执行时间

(3)1bytes的数据库名字长度

(4)2bytes的errorCode

(5)2bytes的statusVar长度

(6)statusVar

(7)以0x00结尾的数据库名称

(8)以0x00皆为的执行SQL,例如update t_temp set name='123' where id=1

###WriteRowsEventData

(1)8bytes的tableId

(2)一个复杂的Bit集合,和下面的Row配合使用

(3)一个Row的列表，表明了插入的行

由于上述几个eventData解析都很复杂，详情请见github

github地址

原文链接