解析MYSQLBINLOG二进制格式(2)--FORMAT_DESCRIPTION_EVENT
原创：转载请说明出处谢谢！
上接
http://blog.itpub.net/7728585/viewspace-2133188/
参考源：
1、源码log_event.h log_event.cc
2、internals-en.epub
class：Format_description_log_event
event：FORMAT_DESCRIPTION_EVENT
MySQL 5.0后所有的binlog 文件都是以FORMAT_DESCRIPTION_EVENT(FED) event开始的,其typecode=15
及0X0F
它的格式为：
1、fixed data part
2 bytes：binlog 的格式版本，我们看到5.6，5.7肯定都是v4
50 bytes：这是一个固定50字节的字符串，显示了mysql server的版本，用0X00补足
也就是第一个0X00表示结尾
4 bytes: 这4个字节文档上说是冗余的，在event header显示，这里看到全是0X00
1 bytes：这个字节直接说明了我们event header的长度，V4为19
var-size：这些字节由已经定义的event的个数定义5.6，5.7为40个，也就是40个字节
说明了他们fixed data(posted header)的长度
2、variable data
无
我们来解析一个实际的二进制格式文件
00000000 fe 62 69 6e bc df 98 58 0f 01 00 00 00 77 00 00 |.bin...X.....w..|
00000010 00 7b 00 00 00 00 00 04 00 35 2e 37 2e 31 34 2d |.{.......5.7.14-|
00000020 37 2d 64 65 62 75 67 2d 6c 6f 67 00 00 00 00 00 |7-debug-log.....|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 13 |................|
00000050 38 0d 00 08 00 12 00 04 04 04 04 12 00 00 5f 00 |8............._.|
00000060 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a 0a |................|
00000070 2a 2a 00 12 34 00 01 55 88 2c 87
mysqlbinlog输出为：
# at 4
#170207 4:42:36 server id 1 end_log_pos 123 CRC32 0x872c8855 Start: binlog v 4, server v 5.7.14-7-debug-log created 170207 4:42:36
BINLOG '
vN+YWA8BAAAAdwAAAHsAAAAAAAQANS43LjE0LTctZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AVWILIc=
'/*!*/;
fe 62 69 6e：binlog开头魔法数 4字节
event header
bc df 98 58：timestamp，小端显示，及0X5898DFBC十进制1486413756，用命令
[root@testmy mysqld.1]# date -d'@1486413756'
Tue Feb 7 04:42:36 CST 2017
可以看见时间和mysqbinlog解析的一致4:42:36
0f：event_type为15
01 00 00 00：service_id,小端显示 0X00000001及1
mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
和mysqlbinlog中的server id 1也是一致的
77 00 00 00：event长度及0X00000077及119，刚好是下一个event 123-4(魔法数)=119
7b 00 00 00：下一个event位置0X0000007b及123，和mysqlbinlog解析的end_log_pos 123一致
00 00：flags，如果为0X0001那么会在MYSQLBINLOG输出中报一个警告说本binlog没有关闭
04 00:binlog 版本，小端显示及0X0004,和mysqlbinlog中的解析Start: binlog v 4一致
35 2e 37 2e 31 34 2d 37 2d 64 65 62 75 67 2d 6c
6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ：
这部分就是50字节的字符串了其ASCII值是5.7.14-7-debug-log和mysqlbinlog中的解析
server v 5.7.14-7-debug-log一致
00 00 00 00：冗余的timestamp,全是0X00
13 38 0d 00 08 00 12 00 04 04 04 04 12 00 00 5f
00 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a
0a 2a 2a 00 12 34 00 01：
这部分是一个数组，表现了已知的40个event的fixed data(posted header)的长度
打个比方说0a 0a 0a 这里刚好array[30],array[31],array[32](C语言以[0]作为数
组的开始)就是我们最要的
WRITE_ROWS_EVENT
UPDATE_ROWS_EVENT
DELETE_ROWS_EVENT
的fixed data(posted header)的长度0X0A也就是10，以后会详细解释
55 88 2c 87: CRC32校验位,小端显示及0X872C8855和mysqlbinlog中的CRC32 0x872c8855一致
到这里FORMAT_DESCRIPTION_EVENT解析完毕
标题名称：解析MYSQLBINLOG二进制格式(2)--FORMAT_DESCRIPTION_EVENT
URL网址：http://hbruida.cn/article/gcojhe.html
上接
http://blog.itpub.net/7728585/viewspace-2133188/
参考源：
1、源码log_event.h log_event.cc
2、internals-en.epub
class：Format_description_log_event
event：FORMAT_DESCRIPTION_EVENT
MySQL 5.0后所有的binlog 文件都是以FORMAT_DESCRIPTION_EVENT(FED) event开始的,其typecode=15
及0X0F
它的格式为：
1、fixed data part
2 bytes：binlog 的格式版本，我们看到5.6，5.7肯定都是v4
50 bytes：这是一个固定50字节的字符串，显示了mysql server的版本，用0X00补足
也就是第一个0X00表示结尾
4 bytes: 这4个字节文档上说是冗余的，在event header显示，这里看到全是0X00
1 bytes：这个字节直接说明了我们event header的长度，V4为19
var-size：这些字节由已经定义的event的个数定义5.6，5.7为40个，也就是40个字节
说明了他们fixed data(posted header)的长度
2、variable data
无
我们来解析一个实际的二进制格式文件
00000000 fe 62 69 6e bc df 98 58 0f 01 00 00 00 77 00 00 |.bin...X.....w..|
00000010 00 7b 00 00 00 00 00 04 00 35 2e 37 2e 31 34 2d |.{.......5.7.14-|
00000020 37 2d 64 65 62 75 67 2d 6c 6f 67 00 00 00 00 00 |7-debug-log.....|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 13 |................|
00000050 38 0d 00 08 00 12 00 04 04 04 04 12 00 00 5f 00 |8............._.|
00000060 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a 0a |................|
00000070 2a 2a 00 12 34 00 01 55 88 2c 87
mysqlbinlog输出为：
# at 4
#170207 4:42:36 server id 1 end_log_pos 123 CRC32 0x872c8855 Start: binlog v 4, server v 5.7.14-7-debug-log created 170207 4:42:36
BINLOG '
vN+YWA8BAAAAdwAAAHsAAAAAAAQANS43LjE0LTctZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AVWILIc=
'/*!*/;
fe 62 69 6e：binlog开头魔法数 4字节
event header
bc df 98 58：timestamp，小端显示，及0X5898DFBC十进制1486413756，用命令
[root@testmy mysqld.1]# date -d'@1486413756'
Tue Feb 7 04:42:36 CST 2017
可以看见时间和mysqbinlog解析的一致4:42:36
0f：event_type为15
01 00 00 00：service_id,小端显示 0X00000001及1
mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
和mysqlbinlog中的server id 1也是一致的
77 00 00 00：event长度及0X00000077及119，刚好是下一个event 123-4(魔法数)=119
7b 00 00 00：下一个event位置0X0000007b及123，和mysqlbinlog解析的end_log_pos 123一致
00 00：flags，如果为0X0001那么会在MYSQLBINLOG输出中报一个警告说本binlog没有关闭
04 00:binlog 版本，小端显示及0X0004,和mysqlbinlog中的解析Start: binlog v 4一致
35 2e 37 2e 31 34 2d 37 2d 64 65 62 75 67 2d 6c
6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 ：
这部分就是50字节的字符串了其ASCII值是5.7.14-7-debug-log和mysqlbinlog中的解析
server v 5.7.14-7-debug-log一致
00 00 00 00：冗余的timestamp,全是0X00
13 38 0d 00 08 00 12 00 04 04 04 04 12 00 00 5f
00 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a
0a 2a 2a 00 12 34 00 01：
这部分是一个数组，表现了已知的40个event的fixed data(posted header)的长度
打个比方说0a 0a 0a 这里刚好array[30],array[31],array[32](C语言以[0]作为数
组的开始)就是我们最要的
WRITE_ROWS_EVENT
UPDATE_ROWS_EVENT
DELETE_ROWS_EVENT
的fixed data(posted header)的长度0X0A也就是10，以后会详细解释
55 88 2c 87: CRC32校验位,小端显示及0X872C8855和mysqlbinlog中的CRC32 0x872c8855一致
到这里FORMAT_DESCRIPTION_EVENT解析完毕
标题名称：解析MYSQLBINLOG二进制格式(2)--FORMAT_DESCRIPTION_EVENT
URL网址：http://hbruida.cn/article/gcojhe.html
