MySQL二进制日志分析-FORMAT_DESCRIPTION_EVENT(包含代码实现)
如前文概述,MySQL Binlog v3以前版本, 二进制日志文件的第一个事件是START_EVENT_V3, 从v4版本开始第一个事件为FORMAT_DESCRIPTION_EVENT(以下简称FD事件),替代掉START_EVENT_V3。具体到MySQL服务器版本来说,MySQL 5.0以前版本二进制日志的第一个事件是START_EVENT_V3,而后续版本的第一个事件都是FD事件,由于目前大部分MySQL都跑在5.0+,所以这里不讨论START_EVENT_V3事件,FD事件可以看成是START_EVENT_V3的继承和扩展,是相通的,有兴趣可以虫github 克隆(clone)BinlogMiner的源代码下来参考。
FD事件比较简单,顺带介绍一下BinlogMiner的程序实现,本文可能很拖沓。
文件I/O是编程语言的基本功能,也是编程的基本功。具体到Java来说,传统方式是通过I/O流来进行文件的读写,如"BufferedInputStream"。Java 1.4版本的开始引入新的IO访问方式Java NIO (New IO) ,其中的MappedByteBuffer允许将一个文件通过FileChannel.map,映射成一个内存缓存,跟简单的来说,映射成一个字节数组,可以通过直接访问数组的方式访问文件。这大大简化了文件的随机读写,而且相较于流方式,更接近人的思考方式,还有极高的读写效率。总的来说Java还是很全面的,对于底层的开发也支持很好,NO.1 霸榜多年还是有道理的。BinlogMiner基于MappedByteBuffer实现的。下面介绍的并非BinlogMiner的代码(因为实际代码需要处理很多细节,不适合来说原理),下面只是举个简单实现能跑的栗子。
只需要简单的3行就可以创建一个MappedByteBuffer:
String binlogFileName = "D:\\build\\binlogs\\5.7.18\\blog.000016";
RandomAccessFile binlogFile = new RandomAccessFile(binlogFileName, "r");
FileChannel binlogFileChannel = binlogFile.getChannel();
MappedByteBuffer blogFileBuffer = binlogFileChannel.map(MapMode.READ_ONLY, 0, binlogFile.length());
最后一行,创建一个将文件(D:\build\binlogs\5.7.18\blog.000016)映射到MappedByteBuffer,只读模式,范围从第一个字节开始(0),到文件结束(binlogFile.length())。通过MappedByteBuffer.position()可以获取当前的文件访问的位置,通过MappedByteBuffer.position(int position)可以设置当前文件访问的位置,在概述的时候提到,前4个字节是二进制文件的幻数(magic number),将访问指针直接跳过,就到了FD事件开始了。
blogFileBuffer.position(4);
int starPos = blogFileBuffer.position(); //记录事件开始位置
这里需要注意的是MappedByteBuffer的position是一个整型,最大的值是Integer.MAX_VALUE。也就是2GB,如果超过2GB,那么就需要重新映射,如:
blogFileBuffer = binlogFileChannel.map(MapMode.READ_ONLY, new_start_position , new_end_position);
这时候MappedByteBuffer的position就是一个相对偏移,需要根据new_start_position_position来获得绝对偏移量,当然对于Binlog不需要担心这个问题,因为截至当前的MySQL 8版本,二进制文件的最大限制还是1GB。
1. Common header的解析
根据前文,事件的第一部分是通用头,根据官方文档: https://dev.mysql.com/doc/internals/en/binlog-event-header.html
Binlog header Payload:
4 timestamp
1 event type
4 server-id
4 event-size
if binlog-version > 1:
4 log pos
2 flags
接下来代码获取文件头的内容:
1.1. timestamp
前4个字节是该事件的时间戳:
byte[] rawTimestamp = new byte[4];
blogFileBuffer.get(rawTimestamp);
根据文档,timestamp是一个无符号的4字节长度的整型,这里需要注意的2个细节是:
- Java没有unsigned关键字,没有无符号数,这里需要用第三放的库或者直接实现无符号数。
- 不同平台,使用不同字节序的概念,如,一个数值,1234,litte-endian存储的是4321,而big-endian存储的是1234。
- 在Java中,通过4个字节记录一个整型,8个字节记录一个长整型,但在binlog中,为节省空间,提高性能,可能是1个字节,2个字节,3个字节,。。。
在BinlogMiner中,是自己写函数实现的无符号数读取,具体可以看PaserHelper(https://github.com/Li-Xiang/BinlogMiner/blob/master/src/org/littlestar/mysql/binlog/parser/ParserHelper.java)这个工具类,这里就不列出来:
ByteOrder order = ByteOrder.LITTLE_ENDIAN; //little-endian,小字节序,x86平台都是。
long timestampValue = ParserHelper.getUnsignedLong(rawTimestamp, order); //获得了存储的值;
//这里获得的timestamp是unix timestamp,是基于秒的,而java的Date是基于毫秒(milliseconds)的,所以这里转换要乘以1000.
Date timestamp = new Date(timestampValue * 1000L);
System.out.println(timestamp.toString()); // 这里就获得了可读的事件日期;
1.2. event type
1个字节的无符号数,描述该事件的类型:
byte[] rawEventType = new byte[1];
blogFileBuffer.get(rawEventType);
int eventTypeValue = ParserHelper.getUnsignedInteger(rawEventType, order);
System.out.print(eventTypeValue);
这里输出的事件类型为15,转换成十六进制为0x0F,根据文档:(https://dev.mysql.com/doc/internals/en/binlog-event-type.html)正好是FD事件。
1.3. server-id
MySQL的服务器id,4字节无符号:
byte[] rawServerId = new byte[4];
blogFileBuffer.get(rawServerId);
long serverId = ParserHelper.getUnsignedInteger(rawServerId, order);
1.4. event-size
该事件的长度(字节数),4字节无符号数;
byte[] rawEventSize = new byte[4];
blogFileBuffer.get(rawEventSize);
long eventSize = ParserHelper.getUnsignedInteger(rawEventSize, order);
1.5. log pos
该事件的结束位置,4字节无符号数,v4版本才包含,v4以前的START_EVENT_V3其实也是可以根据event-size计算得log pos的。
byte[] rawLogPos = new byte[4];
blogFileBuffer.get(rawLogPos);
long logPos = ParserHelper.getUnsignedInteger(rawLogPos, order);
1.6. flags
该事件的标志(https://dev.mysql.com/doc/internals/en/binlog-event-flag.html)
byte[] rawFlags = new byte[2];
blogFileBuffer.get(rawFlags);
long flags = ParserHelper.getUnsignedInteger(rawFlags, order);
至此,事件的通用头分析结束。
2. Event Body
Common Header后就是事件内容(Event Body),先看官方定义:
FORMAT_DESCRIPTION_EVENT:A format description event is the first event of a binlog for binlog-version 4. It describes how the other events are layed out.
Payload:
2 binlog-version
string[50] mysql-server version
4 create timestamp
1 event header length
string[p] event type header lengths
注意:这里的文档写的是Payload,但实际分析的时候会发现,应该理解为前文概述中的post header。实际的playload根据版本不同为1个字节,或者0个字节,用于标识CRC算法,先做个引子,后文会详细说明。
2.1.binlog-version
这里自描述了该二进制日志文件的版本,2个字节无符号数:
byte[] rawBinlogVersion = new byte[2];
blogFileBuffer.get(rawBinlogVersion);
int binlogVersion =ParserHelper.getUnsignedInteger(rawBinlogVersion, order);
System.out.print(binlogVersion); //--> 输出4,v4版本
2.2. mysql-server version
记录了服务器的版本,50个字节,字符串类型。
byte[] rawserverVersion = new byte[50];
blogFileBuffer.get(rawserverVersion);
String serverVersion = new String(rawserverVersion).trim();
System.out.print(serverVersion); //--> 输出 5.7.18-15-log
2.3. create timestamp
二进制文件创建的事件戳。4字节无符号数:
byte[] rawCreateTimestamp = new byte[4];
blogFileBuffer.get(rawCreateTimestamp);
long createTimestampValue = ParserHelper.getUnsignedInteger(rawCreateTimestamp, order);
Date createTimestamp = new Date(createTimestampValue * 1000L);
2.4. event header length
通用头(Common header)的长度, 1个字节,无符号数。
byte[] rawCommonHeaderSize = new byte[1];
blogFileBuffer.get(rawCommonHeaderSize);
int commonHeaderSize = ParserHelper.getUnsignedInteger(rawCommonHeaderSize, order);
System.out.print(commonHeaderSize); //--> 输出是19,除了v1版本,其他版本都是固定的19个字节。
2.5. event type header lengths
这里的是每个事件的post header的长度的字节数组,每一个事件一个字节。
首先这个数组长度不是固定的(每个版本包含的事件数很可能是不同的),还可能包含checksum部分,前文说过,在MySQL 5.6.2版本开始引入Checksum, 这里可能还有Checksum的信息。这部分解析就需要些技巧,首先假设“event type header lengths”一直到事件结束。
int pos = blogFileBuffer.position(); //get current position;
byte[] remainBytes = new byte[logPos - pos]; //根据当前的位置和结束位置,计算出该事件剩余的字节数
blogFileBuffer.get(remainBytes);
那么根据这个数组,FD事件的Post Header的长度是多少?根据官方文档,可以根据(事件的编号-1)作为索引获取:
byte rawFdPostHeaderLength = remainBytes[0x0f - 1]; //FD event = 0x0f
int fdPostHeaderLength = rawFdPostHeaderLength & 0xFF; //这里是byte转无符号int
System.out.println(fdPostHeaderLength); //--> FD的post header长度为95个字节。
可以通过log pos和post header来计算出checksum部分的长度,其中根据官方文档,用1个字节记录checksum类型,剩下的为checksum的值:
long crcSize = logPos - (starPos + 19 + fdPostHeaderLength); // 输出结构--> 5 (1 byte crc type + 4 byte crc value)
所以实际的Post header数组为:
byte[] postHeaderSizeArray = Arrays.copyOfRange(remainBytes, 0, remainBytes.length-5);
2.6. checksum算法
所以checksum的类型,和checksum的值为:
int crcType =remainBytes[postHeaderSizeArray.length] & 0xff;
System.out.println(ParserHelper.getHexString(crcValue)); // --> = 1, 根据文档也就是CRC32
byte[] crcValue = Arrays.copyOfRange(remainBytes, remainBytes.length-(5-1), remainBytes.length);
System.out.println(ParserHelper.getHexString(crcValue));
//--> 本案例的输出为F2FABAC5,可以通过mysqlbinlog比对(0xc5bafaf2), 注意,因为是little-endian平台,这里需要倒过来。
至此,第一个事件分析完毕。最后附上完整代码(注意:ParserHelper来自于BinlogMiner):
import java.io.IOException;
import java.io.RandomAccessFile;
import java.nio.ByteOrder;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.channels.FileChannel.MapMode;
import java.util.Arrays;
import java.util.Date;
import org.littlestar.mysql.binlog.parser.ParserHelper;
public class T2 {
public static void main(String[] args) throws IOException {
String binlogFileName = "D:\\build\\binlogs\\5.7.18\\blog.000020";
RandomAccessFile binlogFile = new RandomAccessFile(binlogFileName, "r");
FileChannel binlogFileChannel = binlogFile.getChannel();
MappedByteBuffer blogFileBuffer = binlogFileChannel.map(MapMode.READ_ONLY, 0, binlogFile.length());
//skip 4 bytes image number;
blogFileBuffer.position(4);
int starPos = blogFileBuffer.position();
//Common Header..
byte[] rawTimestamp = new byte[4];
blogFileBuffer.get(rawTimestamp);
ByteOrder order = ByteOrder.LITTLE_ENDIAN;
long timestampValue = ParserHelper.getUnsignedLong(rawTimestamp, order);
Date timestamp = new Date(timestampValue * 1000L);
byte[] rawEventType = new byte[1];
blogFileBuffer.get(rawEventType);
int eventTypeValue = ParserHelper.getUnsignedInteger(rawEventType, order);
byte[] rawServerId = new byte[4];
blogFileBuffer.get(rawServerId);
long serverId = ParserHelper.getUnsignedInteger(rawServerId, order);
byte[] rawEventSize = new byte[4];
blogFileBuffer.get(rawEventSize);
long eventSize = ParserHelper.getUnsignedInteger(rawEventSize, order);
byte[] rawLogPos = new byte[4];
blogFileBuffer.get(rawLogPos);
int logPos = ParserHelper.getUnsignedInteger(rawLogPos, order);
byte[] rawFlags = new byte[2];
blogFileBuffer.get(rawFlags);
int flags = ParserHelper.getUnsignedInteger(rawFlags, order);
//Event Body
byte[] rawBinlogVersion = new byte[2];
blogFileBuffer.get(rawBinlogVersion);
int binlogVersion = ParserHelper.getUnsignedInteger(rawBinlogVersion, order);
byte[] rawserverVersion = new byte[50];
blogFileBuffer.get(rawserverVersion);
String serverVersion = new String(rawserverVersion).trim();
byte[] rawCreateTimestamp = new byte[4];
blogFileBuffer.get(rawCreateTimestamp);
long createTimestampValue = ParserHelper.getUnsignedInteger(rawCreateTimestamp, order);
Date createTimestamp = new Date(createTimestampValue * 1000L);
byte[] rawCommonHeaderSize = new byte[1];
blogFileBuffer.get(rawCommonHeaderSize);
int commonHeaderSize = ParserHelper.getUnsignedInteger(rawCommonHeaderSize, order);
int pos = blogFileBuffer.position(); //get current position;
byte[] remainBytes = new byte[logPos - pos];
blogFileBuffer.get(remainBytes);
byte rawFdPostHeaderLength = remainBytes[0x0f - 1]; //FD event = 0x0f
int fdPostHeaderLength = rawFdPostHeaderLength & 0xFF; //
System.out.println(fdPostHeaderLength);
long crcSize = logPos - (starPos + 19 + fdPostHeaderLength); // --> 5 (1 byte crc type + crc value)
byte[] postHeaderSizeArray = Arrays.copyOfRange(remainBytes, 0, remainBytes.length-5);
int crcType =remainBytes[postHeaderSizeArray.length] & 0xff;
byte[] crcValue = Arrays.copyOfRange(remainBytes, remainBytes.length-4, remainBytes.length);
System.out.println(ParserHelper.getHexString(crcValue));
binlogFileChannel.close();
binlogFile.close();
}
}