MySql-Binlog协议详解-报文篇
#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地址
https://github.com/alchemystar/Aroundight