MySQL binlog中 format_desc event格式解析

最近想写一个数据库自动恢复的脚本，然后在增量恢复的时候需要用MySQL的二进制日志 binlog。所以研究了一些binlog的格式。

因为MySQL的二进制日志的格式是二进制，所以你无法使用cat，more，tail等查看日志内容。

计算机所记录处理的信息都是01这种二进制，但是一般人无法看懂这些二进制的01序列，所以涉及到进制转换。

知乎中机事本的回答：https://www.zhihu.com/question/19971994

hexdump使用 https://blog.csdn.net/huanhuanq1209/article/details/80900289 

我们可以将二进制文件转换为我们容易识别的16进制文件，然后再结合ASCII码表转换为我们可以读懂的内容。

这样输出就是每个字节为一组，因为1111 最大为15，所以一个16进制数可以表示任何4位的二进制，两个16进制数可以表示任何8位的二进制，即两个16进制的可以表示一个字节（1字节Byte=8位bit）

我们使用hexdump查看一个binlog文件 ，结合MySQL官方文档进行如下解读：

 hexdump -C mysql-bin.000011

[root@Master mysql_data]# hexdump -C mysql-bin.000011 
00000000  fe 62 69 6e 36 d7 b2 5e  0f 65 00 00 00 77 00 00  |.bin6..^.e...w..|
00000010  00 7b 00 00 00 00 00 04  00 35 2e 37 2e 32 31 2d  |.{.......5.7.21-|
00000020  6c 6f 67 00 00 00 00 00  00 00 00 00 00 00 00 00  |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 36 d7 b2 5e 13  |...........6..^.|
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 d2  b9 49 aa 36 d7 b2 5e 23  |**..4....I.6..^#|
00000080  65 00 00 00 1f 00 00 00  9a 00 00 00 80 00 00 00  |e...............|
00000090  00 00 00 00 00 00 ce 63  b5 3a 3a d7 b2 5e 22 65  |.......c.::..^"e|
000000a0  00 00 00 41 00 00 00 db  00 00 00 00 00 00 00 00  |...A............|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 02 00  00 00 00 00 00 00 00 01  |................|
000000d0  00 00 00 00 00 00 00 1e  06 77 16 3a d7 b2 5e 02  |.........w.:..^.|
000000e0  65 00 00 00 50 00 00 00  2b 01 00 00 08 00 02 00  |e...P...+.......|
000000f0  00 00 00 00 00 00 04 00  00 22 00 00 00 00 00 00  |........."......|
00000100  01 00 00 a8 55 00 00 00  00 06 03 73 74 64 04 21  |....U......std.!|
00000110  00 21 00 21 00 05 06 53  59 53 54 45 4d 74 65 73  |.!.!...SYSTEMtes|
00000120  74 00 42 45 47 49 4e dc  dd 2c 6b 3a d7 b2 5e 13  |t.BEGIN..,k:..^.|
00000130  65 00 00 00 33 00 00 00  5e 01 00 00 00 00 6c 00  |e...3...^.....l.|
00000140  00 00 00 00 01 00 04 74  65 73 74 00 01 74 00 04  |.......test..t..|
00000150  03 0f 12 12 04 96 00 00  00 02 7b 1f 95 9c 3a d7  |..........{...:.|
00000160  b2 5e 1f 65 00 00 00 52  00 00 00 b0 01 00 00 00  |.^.e...R........|
00000170  00 6c 00 00 00 00 00 01  00 02 00 04 ff ff f0 06  |.l..............|
00000180  00 00 00 04 72 6f 73 65  99 a6 4d 46 14 99 a6 4d  |....rose..MF...M|
00000190  46 14 f0 06 00 00 00 0a  79 61 6e 68 61 69 68 61  |F.......yanhaiha|
000001a0  6e 67 99 a6 4d 46 14 99  a6 4d 76 b2 2a ab e1 44  |ng..MF...Mv.*..D|
000001b0  3a d7 b2 5e 10 65 00 00  00 1f 00 00 00 cf 01 00  |:..^.e..........|
000001c0  00 00 00 07 00 00 00 00  00 00 00 85 11 fa 7e e4  |..............~.|
000001d0  b4 b3 5e 04 65 00 00 00  2f 00 00 00 fe 01 00 00  |..^.e.../.......|
000001e0  00 00 04 00 00 00 00 00  00 00 6d 79 73 71 6c 2d  |..........mysql-|
000001f0  62 69 6e 2e 30 30 30 30  31 32 8d e4 8a cd        |bin.000012....|

+=====================================+
| event  | timestamp         0 : 4    |
| header +----------------------------+
|        | type_code         4 : 1    | = FORMAT_DESCRIPTION_EVENT = 15
|        +----------------------------+
|        | server_id         5 : 4    |
|        +----------------------------+
|        | event_length      9 : 4    | >= 91
|        +----------------------------+
|        | next_position    13 : 4    |
|        +----------------------------+
|        | flags            17 : 2    |
+=====================================+
| event  | binlog_version   19 : 2    | = 4
| data   +----------------------------+
|        | server_version   21 : 50   |
|        +----------------------------+
|        | create_timestamp 71 : 4    |
|        +----------------------------+
|        | header_length    75 : 1    |
|        +----------------------------+
|        | post-header      76 : n    | = array of n bytes, one byte per event
|        | lengths for all            |   type that the server knows about
|        | event types                |
+=====================================+

binlog的版本官方文档 Binary Log Versions  https://dev.mysql.com/doc/internals/en/binary-log-versions.html

进制转换 https://tool.lu/hexconvert/

时间戳转换 https://tool.lu/timestamp/ 

小端字节序  https://www.cnblogs.com/fan-yuan/p/10406315.html

2 format_desc event 

前面4个字节是固定的magic number,值为0x6e6962fe

event header部分

• 前4个字节 timestime 时间戳    （36 d7 b2 5e mysql日志是小端字节序）  5eb2d736转换为10进制时间戳1588778806 ，时间戳转换为时间 2020-05-07 13:34:22 
• 第5个字节 红色框 type_code  0f =15  表示 FORMAT_DESCRIPTION_EVENT事件
• 后面4个字节 橙色框  65 00 00 00 server_id   00000065 转换为十进制 101
• 后面4个字节 绿色框 event_length 事件长度  00000077=119 
• 后面4个字节 蓝色框 next_position  下一个event的起始位置   0000007b=123
• 接着的2个字节 紫色框 0x0000是flag（1为LOG_EVENT_BINLOG_IN_USE_F，标识binlog还没有关闭，binlog关闭后，flag会被设置为0）

这样4+1+4+4+4+2=19个字节的公共头就完了(extra_headers暂时没有用到)

event data部分

• 前两个字节 0400 代表binlog的版本 为 4  
• 接着的50个字节为mysql-server版本
• 接下来4个字节是binlog创建时间  36 d7 b2 5e 5eb2d736 转换为10进制时间戳  1588778806  转换为具体时间 2020-05-06 23:26:46 
• 然后的1个字节0x13是指之后所有event的公共头长度，这里都是19
• 接着的27个字节中每个字节为mysql已知的event（共27个）的Fixed data的长度；可以发现format_desc event自身的Variable data部分为

另外binlog还有需要其他的event，作用以及描述可以参考官方文档，其他的event分析和 format_desc event 分析解读类似，只要掌握方法与原理即可

参考博客 https://www.jianshu.com/p/c16686b35807

MySQL关于binlog的内部官方文档 https://dev.mysql.com/doc/internals/en/binary-log.html