binlog文件格式有以下几种:
v1:用于3.23版本
v3:用于4.0.2到4.1版本
v4:用于5.0及以上版本
v2版本只在4.0.x版本中使用,目前已经不再支持了。
处理binlog的程序必须支持以上所有的版本。这部分描述了服务器是如何区分所有的格式的,以便辨别binlog使用的版本。mysqlbinlog也是使用的相同的规则。
重要的常量:
START_EVENT_V3=1
FORMAT_DESCRIPTION_EVENT=15
EVENT_TYPE_OFFSET=4
EVENT_LEN_OFFSET=9
ST_SERVER_VAR_LEN=50
binlog文件以一个4字节的魔法数开头,后面跟着一个初始的描述事件,标志文件的格式。
在v1和v3中,这个事件被称为开始事件(start event)
在v4中,被称为格式描述事件(format description event)
各个版本中,描述事件的头和数据部分如下:
v1开始事件(69字节)
+=====================================+
| event | timestamp 0 : 4 |
| header +----------------------------+
| | type_code 4 : 1 | = START_EVENT_V3 = 1
| +----------------------------+
| | server_id 5 : 4 |
| +----------------------------+
| | event_length 9 : 4 | = 69
+=====================================+
| event | binlog_version 13 : 2 | = 1
| data +----------------------------+
| | server_version 15 : 50 |
| +----------------------------+
| | create_timestamp 65 : 4 |
+=====================================+
v3开始事件(75字节)
+=====================================+
| event | timestamp 0 : 4 |
| header +----------------------------+
| | type_code 4 : 1 | = START_EVENT_V3 = 1
| +----------------------------+
| | server_id 5 : 4 |
| +----------------------------+
| | event_length 9 : 4 | = 75
| +----------------------------+
| | next_position 13 : 4 |
| +----------------------------+
| | flags 17 : 2 |
+=====================================+
| event | binlog_version 19 : 2 | = 3
| data +----------------------------+
| | server_version 21 : 50 |
| +----------------------------+
| | create_timestamp 71 : 4 |
+=====================================+
v4格式描述事件(大于等于91字节,大小=76+事件类型的数字)
+=====================================+
| 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版本中,描述事件的数据部分包含的部分相同字段:
binlog_version
binlog版本数字(1、3或4)
server_version
服务器版本,字符串
create_timestamp
创建时间戳,如果不等于0,等于事件创建的秒数;这表示binlog文件穿件的时间。这个字段实际上没有值,如果不为零,也是重复的,因为与头中的timestamp一样。
注意:这个字段是为将来使用的,程序不应该依赖于这个值。这个值将来可能有其他的用处。
v4版本的格式描述事件数据中包含两个额外的字段,以便解析其他类型的事件:
header_length:事件头的长度。这个值包含extra_headers字段,所以这个头的长度19不包含extra字段。
post-header lengths:每个事件固定数据部分的长度。
决定binlog版本
给定任何binlog文件,这部分的信息描述了如何决定文件格式。几个关于描述事件格式的重要点:
v1的头字段对于所有的格式通用。(v3和v4的头也是以v1的头字段开始的,新增了next_position和标志位字段)
v3和v4的头包含相同的字段。v3和v4的数据部分不一样,v4的数据部分允许在不改变头的情况的扩展格式。
可以简单的通过读取binlog_version字段的两个字节,来决定binlog的版本,如果不是因为这个字段在v1和v3/v4的位置不一样的话。因此,有必要通过文件的第一个事件是不是v1的开始事件来决定binlog版本。
为了判断binlog版本,通过下面的步骤:
这个文件以一个4字节的魔法数开头。跳过他,获取到文件中的第一个事件(大多数情况下,这个事件是开始事件或者格式描述事件)
通过第一个事件,读取两个值:
事件的EVENT_TYPE_POSITION(4)位置的1字节的类型编码
事件中第EVENT_LEN_OFFSET(9)位置的4字节的事件长度的值
如果类型编码不是START_EVENT_V3或者FORMAT_DESCRIPTION_EVENT,文件格式是v3
如果类型编码是START_EVENT_V3(1),检查事件长度。如果长度小于75,文件格式是v1,否则是v3。为什么是75?因为这是v3开始事件的长度:
头(19字节)
binlog版本(2字节)
服务器版本(ST_SERVER_VER_LEN=50字节)
时间戳(4字节)
把这些加起来19+2+50+4=75。因此,如果事件长度小于75,就一定是v1版本。
如果类型编码是FORMAT_DESCRIPTION_EVENT(15),文件格式是v4。
但是,有几种特殊情况需要处理:
异常情况1:在4.0和4.1版本中,binlog的第一个事件可能不是开始事件。因为服务器只会在它启动后的第一个binlog文件中写开始事件。对于其他的文件,服务器会在当前日志文件的结尾处写一个ROTATE_EVENT事件,这样在下个文件的开头就不会写开始事件了。如果日志文件的开头不是START_EVENT_V3或者FORMAT_DESCRIPTION_EVENT,可以断定是v3版本,因为这只会出现在4.0和4.1版本中,而这两个版本的版本都是v3格式的。
异常情况2:在5.1和5.2版本的Mysql中,有些较早的版本用v4格式写binlog文件,但是使用的时间号与现有的v4不一样。因此,当读取FDE时才会发现是v4版本,这种情况下,还需要读取在21位置出现的字符串,表示服务器版本。如果版本号在受影响版本的集合中,事件会重新编号为v4。