码迷,mamicode.com
首页 > 数据库 > 详细

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

时间:2018-09-22 19:57:58      阅读:658      评论:0      收藏:0      [点我收藏+]

标签:表示   body   结果   不包含   header   方式   读取   delete   恢复   

本系列博客主要介绍MySQL数据库的binlog日志的相关内容,这个系列的主题包括:

MySQLbinlog日志01binlog日志基本操作

MySQLbinlog日志02binlog日志用于数据恢复

MySQLbinlog日志03binlog日志字节码解析

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

 

前一篇博客介绍了 

MySQLbinlog日志03binlog日志字节码解析

本篇博客将接着介绍Write Rows事件的字节码解析。

 

7.Write rows事件

现在来解析insert语句对应的核心binlog事件:Write rows事件。这个事件用于insert/update语句产生的增加和修改行数据的记录。每个Write rows事件只涉及对一行数据的增加或者修改,尽管这个事件的名字用了复数形式。

技术分享图片

 

对应的字节码数据如下所示:

技术分享图片

common header的内容如下:

时间戳:

技术分享图片

 

字段

字节码

时间戳

8191a35b

2018-09-20 20:24:33 

事件类型

1e

30

MySQL server-id

65000000

101

本事件的长度

3b000000

59

下一个事件的开始位置

5e140000

5214

标志

0000

0

 

 

 

Write rows事件的事件相关头结构格式还是从源代码注释中找到的,总体结构如下:

技术分享图片

 

 

各个条目细分后的具体含义如下:

条目

长度

事件

偏移

备注

id

6

0

 

标志

2

6

 

var_header_len

2

8

 

附加行数据

 

 

取决于var_header_len的值

列的个数

2

8

Npacked integer

列标志

变长

 

INT((N + 7) / 8,每个列1bit

操作前列数据标志

变长

 

定位行数据用到的列:INSERT/DELETE

操作后列数据标志

变长

 

修改后的列:UPDATE,本例中没这部分。

行数据

变长

 

是否为NULL标志+1的值+2的值+...

 

 

 

Write rows事件自身的字节码数据如下:

技术分享图片

id6个字节,值为120

标志占2个字节,值为1

var_header_len2个字节,值为2字节。包含了自身的长度以及附加行数据的长度。因此这个事件中没有附加行数据。

接着是列的个数,这个整数的编码规则比较复杂。下面这个代码用于读取这样的列的个数的字节码。具体代码如下所示:

技术分享图片

这个事件中第1个字节为06,因此列的数量就是6个列,仅仅占用1个字节。

接着是操作前的行记录用到的列的标志。对于INSERT语句而言,不包含这一部分。对于UPDATE/DELETE而言,就是mysqlbinlog输出的WHERE中用到哪些列。因此具体格式在操作后的部分进行描述。

接着是操作后的行记录用到的列的标志。长度是(6+7)/8=1个字节,值为ff,只有6个二进制位有效。可以看到这个6个字段都被使用到了。这1个字节仅仅是标志位,不是实际的列数据。对于INSERT语句而言,就是新增的记录数据中包含哪些列。对于UPDATE而言,就是SET中用到哪些列。

最后是真正的行记录的列数据。因为在common header中已经知道了整个事件的长度,而此时前面这些部分的长度也已经确定了,那么列数据的长度也可以计算出来。实际上就是分析到此时的偏移量开始,到事件结束位置的前1字节为止的这个范围内的字节码。

技术分享图片

列数据具体是怎么存储的,稍后介绍。

行数据先经过pack_row()函数进行组装后才写入到binlog文件中。pack_row()函数的代码经过精简后如下所示:

技术分享图片

 

先存储NULL标记,即值为NULL的列标记,每个列用一个位来表示其后的值是否为NULL

t1表只有6个列,因此这里值为NULL的列只可能占用1个字节。当前事件中这个值为0xc0

最后6位全部是0,这6个列当前的值全部不为NULL

技术分享图片

 

接着依次存储每个值不是NULL的列的具体数据。

每一种类型的列都有对应的pack()函数。前面已经知道了t1表的6个列中,第2列(name)是varchar之外,其它列都是intint类型的列在MySQL源代码中定义为Field_long类。

技术分享图片

功能主要就是这个32位整数存储为Big endian格式的字节码,占用4个字节。

varchar类型的列对应的类是Field_varstring

技术分享图片

 

对于varstring,先存储字符串的长度,再存储实际的字符串。整数类型的列的存储方式和前面介绍的各种长度的存储方式是类似的,都可以认为是big-endian格式,而这里的字符串长度,是按照little-endian格式存储的。小于255字节,存储为1个字节,否则存储为2个字节。

 

现在来解析这个Write rows事件中包含的列的值,即行记录的具体数据。

技术分享图片

 

 

 

字节码

NULL标记

c0

11000000.6列的值均不为NULL

1

0200 0000

INT2

2

024132

VARSTRINGA2

3

1500 0000

INT:21

4

1600 0000

INT:22

5

1700 0000

INT:23

6

1800 0000

INT:24

 

这个结果与使用mysqlbinlog提取的结果是一致的:

技术分享图片

 

最后面4个字节是这个binlog事件的校验码。

至此,INSERT语句对应的Write row事件的字节码解析完毕。UPDATEDELETE语句对应的binlog事件的字节码解析方式跟这个非常类似,就不再赘述了。

 MySQL数据库binlog系列博客就是这些内容了。

 

 

 

 

 

 

 

MySQLbinlog日志04binlog日志字节码解析之二Write_Rows事件

标签:表示   body   结果   不包含   header   方式   读取   delete   恢复   

原文地址:https://www.cnblogs.com/coe2coe/p/9690708.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!