【文档】五、Mysql Binlog事件结构

这个部分描述了事件被写入binlog或者delay log中的属性。所有的事件有相同的整体结构，也就是包含事件头和事件数据：

+===================+
| event header      |
+===================+
| event data        |
+===================+

具体的内容随着Mysql版本的升级而不同，这导致了binlog格式的不一致：

• v1：用于3.23版本
• v3：用于4.0.2到4.1版本
• v4：用于5.0及以上版本

v2的格式用于4.0.x的版本中，但是已经过期了，并且不再支持了。

有些事件的结构随着版本没有改变，而有些与版本有关。在所有的版本中，不同类型的事件在数据部分的结构不一样。

日志文件的第一个事件是特殊的。他是个符号事件，包含binlog版本和服务器版本。符号事件中的信息让程序能够决定日志文件的格式，这样剩余的事件内容才能被正确的解析出来。

下面说明下不同版本的binlog格式：

v1事件结构：

+=====================================+
| event  | timestamp         0 : 4    |
| header +----------------------------+
|        | type_code         4 : 1    |
|        +----------------------------+
|        | server_id         5 : 4    |
|        +----------------------------+
|        | event_length      9 : 4    |
+=====================================+
| event  | fixed part       13 : y    |
| data   +----------------------------+
|        | variable part              |
+=====================================+

头长度=13字节，数据长度=(事件长度-13)字节，y与事件类型有关。

v3事件结构

+=====================================+
| event  | timestamp         0 : 4    |
| header +----------------------------+
|        | type_code         4 : 1    |
|        +----------------------------+
|        | server_id         5 : 4    |
|        +----------------------------+
|        | event_length      9 : 4    |
|        +----------------------------+
|        | next_position    13 : 4    |
|        +----------------------------+
|        | flags            17 : 2    |
+=====================================+
| event  | fixed part       19 : y    |
| data   +----------------------------+
|        | variable part              |
+=====================================+

头长度=19字节，数据长度=（事件长度-19）字节，y与事件类型有关。

v4事件结构

+=====================================+
| event  | timestamp         0 : 4    |
| header +----------------------------+
|        | type_code         4 : 1    |
|        +----------------------------+
|        | server_id         5 : 4    |
|        +----------------------------+
|        | event_length      9 : 4    |
|        +----------------------------+
|        | next_position    13 : 4    |
|        +----------------------------+
|        | flags            17 : 2    |
|        +----------------------------+
|        | extra_headers    19 : x-19 |
+=====================================+
| event  | fixed part        x : y    |
| data   +----------------------------+
|        | variable part              |
+=====================================+

头长度=x字节，数据长度=（事件长度-x）字节，固定数据部分长度=y字节，变量数据程度=（事件长度-(x+y)）字节。x由FDE（格式描述事件format description event）header_length给出。当前来说，x=19，所以extra_headers字段是空的。

y和事件类型有关，也是由FDE给出的。fixed-part的长度对于同一个事件类型是一样的，但是不同的事件类型是不一样的。

fixed-part有时候指的是post-header，变量部分有时候指的是payload或者body。

一、事件内容-写入约定

事件内容的写入约定如下：

• 数字是按照地位优先的格式写入的（最不重要字节有限），除非显式表示
• 表示位置或长度的值以字节形式写入，并且是无符号的
• 有些数字是以封包整数的形式写入的，这个格式后面再详细说明

• 字符串有以下几种格式：

  • 字符串可能写入一个固定长度域中，右边以null填充（0x00）
  • 可变长度的字符串前面包含一个表示字符串长度的内容
  • 有些可变长度的字符串以null结尾，有些不是。每个字符串中有符号表示属于哪种情况。
  • 对于null结尾的字符串，最前面是字符串长度，这个长度不包含结尾的null字节，除非显式表明
  • 如果存在可变长度的字符串在事件结尾，并且事件前面没有任何内容，这个字符串的长度=事件长度-事件中其他内容的长度。

有些事件使用封包整数，这是一个特殊的格式，用来有效的描述无符号整数。封包整数可以存储一个8字节的整数，小整数（small integer）占用1、3或4字节。根据下面的表格，第一个字节的值决定了如何读这个数字：

二、事件头字段

每个事件以LOG_EVENT_HEADER_LEN长度开头，这个常量在v1格式中时13，在v3及以上格式中是19.

• v1：13字节：timestamp+type code+server ID+event length
• v3：19字节：v1的字段+next position+flags
• v4：19字节或更多：v3的字段+可能有其他信息

v1事件头：

+============================+
| timestamp         0 : 4    |
+----------------------------+
| type_code         4 : 1    |
+----------------------------+
| server_id         5 : 4    |
+----------------------------+
| event_length      9 : 4    |
+============================+

v1头的13个字节也包含在其他版本的事件头中。

v3事件头

+============================+
| timestamp         0 : 4    |
+----------------------------+
| type_code         4 : 1    |
+----------------------------+
| server_id         5 : 4    |
+----------------------------+
| event_length      9 : 4    |
+----------------------------+
| next_position    13 : 4    |
+----------------------------+
| flags            17 : 2    |
+============================+

和v1对比，v3以上中的事件头中包含两个额外的字段，总长度为19字节。

v4事件头

+============================+
| timestamp         0 : 4    |
+----------------------------+
| type_code         4 : 1    |
+----------------------------+
| server_id         5 : 4    |
+----------------------------+
| event_length      9 : 4    |
+----------------------------+
| next_position    13 : 4    |
+----------------------------+
| flags            17 : 2    |
+----------------------------+
| extra_headers    19 : x-19 |
+============================+

v4的事件头中包含一个extra_headers字段，是为了以后扩展用。当前x=19，所以v4和v3当前格式一样。

注意：extra_headers么有在FORMAT_DESCRIPTION_EVENT或ROTATE_EVENT的头中出现。

在log_event.h中，包含几个事件头的常量：

• EVENT_TYPE_OFFSET = 4
• SERVER_ID_OFFSET = 5
• EVENT_LEN_OFFSET = 9
• LOG_POS_OFFSET = 13
• FLAGS_OFFSET = 17

事件头中包含以下信息：

• timestamp

4字节。表示的是语句开始执行的时间，格式与TIMESTAMP SQL数据类型一样。

• type_code

1字节。事件类型。1表示START_EVENT_V3，2表示QEURY_EVENT，以此类推。这些数字定义在log_event.h的Log_event_type的枚举类中。

• server id

4字节，产生这个事件的mysqld服务器id。这个是在服务器中配置文件配置的，用于主从复制。server id会在循环复制时避免死循环（开启了--log-slave-updates配置）。假设M1、M2和M3的server id分别是1、2、3，而且他们循环复制：M1是M2的主，M2是M3的主，M3是M1的主。他们的主从关系如下：

M1---->M2
 ^      |
 |      |
 +--M3<-+

客户端发起了一个插入语句给M1，M1执行了之后，写入了M1的binlog文件中，包含了server id为1。这个事件被发给了M2，M2也执行了这个语句，然后写binlog的时候，server id还是1，因为这个事件最初是由M1发起的。然后M3也收到了这个事件，执行完成后写入到M3的binlog文件时，server id还是1。然后M1收到了这个事件之后，在执行插入语句之前，可以分析出server id=1，也就是这个语句最初是本机发起的，这个语句会被忽略执行。

• event_length

4字节。事件的总长度，包含事件头和事件数据。大部分的事件小于1000字节，除非使用LOAD DATA INFILE（因为包含加载文件，所以他们可能很大）

• next_position(v1不包含)：4字节。下个时间在master的binlog中的位置。这个格式在binlog和relay log中不一样，而且与server版本有关（对于relay log来说，与master的版本有关）

  • v3版本的binlog：事件开头的偏移量，从binlog文件的开头开始计算。也就是说，在事件写入之前，等于tell()的值。
    所以binlog的第一个事件的next_position=4，对于事件n和n+1，next_position(n+1)=next_position(n)+event_length(n)。
  • v3版本的relay log，master是v1：可能是0，但是没法测试，因为现在已经基本没有3.23的服务器了。
  • v3版本的relay log，master是v3：开头事件的偏移量和master中binlog文件一样，也是从master的binlog文件开头开始计算。
  • v4版本的binlog：事件结尾的偏移量，从binlog文件开头开始计算。也就是说，等于在事件被写入之后，正好等于tell()的值。所以binlog中第一个事件的next_position=4+event_length，对于事件n和n+1，next_position(n+1)=next_position(n)+event_length(n+1)。
• flags（v1中没有）

2字节，详见下一节。

• extra_headers(v1和v3中不存在)

可变大小，当前为0。

事件flag

对于v3及以上版本中，事件头中包含一个2字节的时间flag在FLAGS_OFFSET=17位置上。在log_event.h中并没有定义。

当前的事件flag：

• LOG_EVENT_BINLOG_IN_USE_F=0x1（5.0.3新增）

表示一个binlog文件是否正确的被关闭了。这个标志位只对FORMAT_DESCRIPTION_EVENT生效。当这个事件被写入日志文件时，才会设置这个标志位。当日志文件后续被关闭后，这个标志位会被清除掉。（这是Mysql修改已经写完的binlog文件的唯一情况）。

• LOG_EVENT_THREAD_SPECIFIC_F=0x4(4.1.0新增)

仅供mysqlbinlog使用，使他能够正确的处理临时表。mysqlbinlog把binlog中的事件打印出来，让你能够理解打印出来的内容。但是如果两个独立的线程使用同样的临时表名，比如：

<thread id 1>
CREATE TEMPORARY TABLE t (a INT);
<thread id 2>
CREATE TEMPORARY TABLE t (a INT);

这种情况下，简单的执行sql语句，会导致表t已经存在的错误。所以使用临时表的事件需要设置这个标志位，那样mysqlbinlog知道需要在变量值钱设置假的线程id，例如：

SET PSEUDO_THREAD_ID=1;
CREATE TEMPORARY TABLE t (a INT);
SET PSEUDO_THREAD_ID=2;
CREATE TEMPORARY TABLE t (a INT);

这样，服务器接收到命令后就没有歧义了。所有情况下都打印SET PSEUDO_THREAD_ID，及时临时表没有用到，这样不会产生bug，但是会有点慢。

• LOG_EVENT_SUPPRESS_USE_F=0x8（4.1.7新增）

在一个语句被记录前，抑制产生USE语句。用于任何不需要使用默认数据库的事件中，比如CREATE DATABASE和DROP DATABASE。

• LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F=0x10（5.1.4新增）

在事件写入日志文件中后，导致binlog内部的表映射版本增加。

过时的标志位：

• LOG_EVENT_TIME_F（4.1.1过期）。从未被设置过
• LOG_EVENT_FORCED_ROTATE_F（4.1.1过期）：这个标志位是在master的ROTATE_EVENT中配置的，但是没有任何用处。

三、事件数据字段（事件详细信息）

事件数据部分的结构依赖于事件类型：

• v1和v3版本中，事件类型完全决定了数据格式
• v4中，数据部分的解析除了依赖于事件类型，还依赖于格式描述事件的信息。这是因为在v4中，允许包含一个extra headers字段，这个字段的大小是在格式描述事件中定义的。实际上，当前这个字段是空的。

数据部分包含固定大小和可变大小两部分。两部分都可以为空，这由事件类型决定。（比如，STOP_EVENT只包含头，数据内容都为空）。

事件数据的大小=事件大小-事件头大小。下面的规则对binlog中所有的事件都通用：

• 对于所有相同类型的事件，固定部分的大小一样。
• 对于所有相同类型的事件，可变部分的大小可能不一样。