Mysql binlog 解析

最新推荐文章于 2024-07-30 04:00:46 发布

weixin_34168700

最新推荐文章于 2024-07-30 04:00:46 发布

阅读量93

点赞数

文章标签：数据库

原文链接：http://blog.51cto.com/11461240/1765412

版权

首先，我们知道MySQL本身就带有replication的机制，我们需要伪造一个slave，向master注册，这样的话master才会发送binlog event。注册很简单，通过调用limysql.so中的cli_advanced_command（），指定binlog filename+position，向master发送COM_BINLOG_DUMP命令。在发送dump命令的时候，我们可以指定flag为BINLOG_DUMP_NON_BLOCK，这样master在没有可以发送的binlog event之后，就会返回一个EOF的包。数据包的具体格式如下：

例如COM_BINLOG_DUMP类型的数据包payload（数据包体）是这样的：

3.1.2 接收事件

通过调用libmysql.so库中的cli_safe_read（）函数，获得master发过来的数据，每次获得一个事件记录的数据，cli_safe_read（）的返回值标示了从master发送过来的数据的数据字节数。而发送过来的数据保存在mysql->net->read_pos数组中。

3.2 Binlog事件

通过调用libmysql.so库中的cli_safe_read（）函数可以获取一次binlog事件。

MySQL的Binlog事件类型有27种，在MySQL5.6之后增加到38种，但是我们只介绍与ROW模式相关的事件，所有的event都含有如下通用的事件结构：

+===============================+

| event header |

+===============================+

| event data |

+===============================+

分别为事件头和事件体组成，而事件的内部结构随MySQL版本的不同而变化着，我们需要用到的版本为v4，用于mysql5.1及以上，其他版本就不做介绍了，想要了解的朋友可以参考官方文档。下图为v4版本的event header格式。

由于各个事件的事件头一致，这里我们就不重复介绍了，后面各个事件我们也将忽略对事件头字段的描述。

3.2.1 ROTATE_EVENT

ROTATE_EVENT, 记录了接下来要请求的binlog的信息。格式如下：

它里面其实就是标明下一个event所在的binlog filename和position。这里需要注意的是，当slave发送binlog dump之后，master会首先发送一个ROTATE_EVENT，用来告知slave下一个event所在的位置，然后才跟着其他事件。

3.2.2 QUERY_EVENT

QUERY_EVENT, 存储的是SQL，主要是一些与数据无关的操作，如begin，alter table，drop table,create table等。格式如下

3.2.3 TABLE_MAP_EVENT

TABLE_MAP_EVENT,记录了某个table所对应的表信息，在其中存储了数据库名和表名等。格式如下：

在这个事件中我们需要注意的是，虽然我们可以用表的id标识符table_id来代表一个特定的表，但是因为alter table或rotate binlog event等原因，master会改变某个table的table_id，所以我们在外部不能使用这个table_id来索引某个table。

还需要关注的就是里面的column meta信息，后续我们解析ROW_EVENT的时候会根据这个来处理不同类型的数据。

3.2.4 ROWS_EVENT

ROWS_EVENT,包含了insert，update，以及delete三种event，并且有v0，v1，v2三个版本。ROWS_EVENT的基本格式如下：

在这里MySQL5.6开始event的type发生变化了，所以MySQL5.6需要改一下，

所以为了我们软件的版本兼容性，我们需要在软件中支持不同的版本。

MySQL5.1~MySQL5.6

· TABLE_MAP_EVENT:19

· WRITE_ROWS_EVENT: 23

· UPDATE_ROWS_EVENT: 24

· DELETE_ROWS_EVENT: 25

MySQL5.6以上

· TABLE_MAP_EVENT:19

· WRITE_ROWS_EVENT: 30

· UPDATE_ROWS_EVENT: 31

· DELETE_ROWS_EVENT: 32

ROWS_EVENT的table_id跟TABLE_MAP_EVENT一样，虽然table_id可能变化，但是ROWS_EVENT和TABLE_MAP_EVENT的table_id是能保证一致的，所以我们也是通过这个来找到TABLE_MAP_EVENT的。

为了节省空间，ROWS_EVENT里面对于各列状态都是采用bitmap的方式来处理的。首先我们需要得到column present bitmap的数据，这个值用来表示当前列的一些状态，如果没有设置，也就是某列对应的bit为0，表名该ROWS_EVENT里该列的数据，外部用null代替就可以了。

然后就是每个record里的bitmap，这个是用来表明一行实际的数据里面有哪些列是NULL的，如果该列为NULL，则为1。

在得到column_bitmap和null_bitmap后，我们就可以实际解析这行对应的数据了，对于每一列，首先判断是否column_bitmap标记了，如果为0，这跳过用null表示，然后再看是否null_bitmap里面标记了，如果为1，则表明为null。

但是，因为我们得到的是一行数据的二进制流，又如何将一列数据解析出来呢，这里就需要靠TABLE_MAP_EVENT里的column_meta了。Column_def中定义了该列的数据类型，对于一些特定的类型，譬如MYSQL_TYPE_LONG，MYSQL_TYPE_TINY等，长度都是固定的，所以我们可以直接读取对应长度的数据得到实际的值，但对于一些类型，则没有这么简单。这时候就需要通过meta来辅助计算了。举个例子：

MYSQL_TYPE_BLOB类型，meta为1表示的为tinyblob，第一个字节解释blob的长度，2表名的是shortblob，前两个字节为blob的长度等，而对于MYSQL_TYPE_VARCHAR，meta存储的则是string的长度，下一小节我们介绍每一种类型的计算方法。

3.2.5 XID_EVENT

XID_EVENT一般出现在一个事务操作之后或者其他语句提交之后。它的主要作用提交事务操作和把事件刷新至binlog文件中。里面存的是8个字节的事务ID号。

3.3 不同的数据类型的长度

上一节我们介绍了在不同事件的事件格式以及需要注意的事项，在其中ROWS_EVENT事件中，在record中bit_map之后的列数据中，针对不同的数据类型，可能在record中占用不同的字节，因从需要针对每种数据类型进行处理，

下面列出大部分常用数据类型的字节数和解析方法：

3.3.1 MYSQL_TYPE_INT家族

3.3.2 MYSQL_TYPE_DOUBLE家族

MYSQL_TYPE_NEWDECIMAL类型

声明语法为decimal(M,D),decimal参量的取值范围如下：

M为数字的最大数(精度),其范围为1~65，默认为10

D是小数点后面的数目(标度)。范围为0~30，但不得超过M

table_map_event中的metadata为2个字节，它会记录该类型的精度和标度，其中第一个字节表示精度，第二个字节表示精度。那么数据的长度是如何计算的呢？

比如说decimal(15,5)a=1234567890.12345，那么a的精度为15，标度为5，所以a的整数位最多为10，mysql中每9个数字用一个32位4个字节的×××来存储，剩下不够9个字节的按照如下方式：

intdig2byte[10] = {0,1,1,2,3,3,3,4,4,4};

该数组表示剩下几个字节的数字用几个字节存储。为什么这样做呢，我们知道一个int型变量能存储的最大整数位2^32，是一个十位数的整数，所以最多可以表示9位数的数字。binlog中的decimal按照小数点前后分别存储，所以a的整数位需要2个int型来存储，小数后的计算方式也一样，需要3个字节存储，所以decimal(15,5)在binlog中需要11个字节来存储数据