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。
