解析MYSQL BINLOG 二进制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 原创:转载请说明出处谢谢! 上接 http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二进制格式(1)--准备工作  http://blog.
原创:转载请说明出处谢谢!
上接
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二进制格式(1)--准备工作 
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二进制格式(2)--FORMAT_DESCRIPTION_EVENT 
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二进制格式(3)--QUERY_EVENT 
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二进制格式(4)--TABLE_MAP_EVENT 
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT 

class:Update_rows_log_event
event:UPDATE_ROW_EVENT
event_code:31


class:Delele_rows_log_event
event:DELETE_ROW_EVENT
event_code:32


自从5.1.18开始,row模式下的update/delete的event
这部分将UPDATE_ROW_EVENT和DELETE_ROWS_EVENT放到一起因为了有了前面WRITE_ROW_EVENT 的
基础这两个基本和他一致,只是要注意UPDATE_ROW_EVENT存放了前后印象
--fixed data  10字节(5.6,5.7中描述为 ROWS_HEADER_LEN_V2)
  6 bytes 表ID
  2 bytes 保留
  2 bytes 文档中并没有描述
  源码中描述为:
  uchar    *m_extra_row_data;   /* Pointer to extra row data if any */
                                /* If non null, first byte is length */
  具体参考前面一篇(解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT)
--variable data part
  packed integer:表中字段个数,这个地方为packed integer自行参考源码
                  uchar *net_store_length或者参考第一章
                  (解析MYSQL BINLOG 二进制格式(1)--准备工作 )
  var-size:文档解释为每一位代表是否字段用到了 长度为INT((n+7)/8) n代表字段数量
           源码描述为 m_cols; /* Bitmap denoting columns available */
           测试表现这一字节和binlog_row_image设置有关,默认为FULL每一个字节始终为
           0XFF 
  var-size-update:UPDATE_ROW_EVENT专用和前面描述的一致,但是表示的是后印象,也就是update后的数据
  
  var-size:每一位代表的字段的值是否为NULL,长度为INT((n+7)/8) n代表字段数量,
  他采用一个位图的方式。
           1:NULL
           0:NOT NULL
  var-size:这部分就是真正的数据了。
    
  var-size-update:
  var-size-update:
  这两部分为UPDATE_ROW_EVENT专用和前面描述的两部分一致,但是表示的是后印象,也就是update后的数据
  
接下来进行实际的解析:
执行语句
mysql> select * from testnull2;
+------+-------+-------+
| id   | name1 | name2 |
+------+-------+-------+
| NULL | test  | NULL  |
+------+-------+-------+
1 row in set (0.01 sec)


mysql> update testnull2 set id=2,name2='test',name1=NULL where name1='test';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0


mysql> delete from testnull2;
Query OK, 1 row affected (0.02 sec)


使用./infobin (自己开发 我放到了云盘)
http://pan.baidu.com/s/1jHIWUN0


[root@testmy data]# ./infobin  test.000184
Check is Little_endian
Author: gaopeng QQ:22389860 Mail: gaopp_200217@163.com 
Waring: This tool only Little_endian platform!
Little_endian check ok!!!
-------------Now begin--------------
Check Mysql Version is:5.7.13-log
Check Mysql binlog format ver is:V4
------------Detail now--------------
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1486949924 Event_size:65(bytes) 
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000450
-->Query Event:Pos:259(0X103) N_Pos:331(0X14b) Time:1486949924 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos331(0X14b) N_pos:389(0X185) Time:1486949924 Event_size:58(bytes) 
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000450 
>Xid Event:Pos:441(0X1b9) N_Pos:472(0X1d8) Time:1486949924 Event_size:31(bytes) 
COMMIT 1000450 /*!add by tool*/
>Gtid Event:Pos:472(0X1d8) N_pos:537(0X219) Time:1486949930 Event_size:65(bytes) 
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1000451
-->Query Event:Pos:537(0X219) N_Pos:609(0X261) Time:1486949930 Event_size:72(bytes) 
Exe_time:0  Use_db:test Statment(35b-trun):BEGIN
---->Map Event:Pos609(0X261) N_pos:667(0X29b) Time:1486949930 Event_size:58(bytes) 
TABLE_ID:210 DB_NAME:test TABLE_NAME:testnull2
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000451 
>Xid Event:Pos:712(0X2c8) N_Pos:743(0X2e7) Time:1486949930 Event_size:31(bytes) 
COMMIT 1000451 /*!add by tool*/


可以看到我们的update和delete的位置
------>Update Event:Pos:389(0X185) N_pos is:441(0X1b9) time:1486949924 event_size:52(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000450 
------>Delete Event:Pos:667(0X29b) N_pos:712(0X2c8) Time:1486949930 Event_size:45(bytes) 
Dml on table: test.testnull2  table_id:210 Gno:1000451 


现在使用mysqlbinlog --hexdump -vv 进行解析


先来看update event
二进制解析
# at 389
#170213  9:38:44 server id 93157  end_log_pos 441 CRC32 0x21c0591d 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      185 24 0e a1 58   1f   e5 6b 01 00   34 00 00 00   b9 01 00 00   00 00
#      198 d2 00 00 00 00 00 01 00  02 00 03 ff ff fd 04 74 |...............t|
#      1a8 65 73 74 fa 02 00 00 00  04 74 65 73 74 1d 59 c0 |est......test.Y.|
#      1b8 21                                               |.|
#       Update_rows: table id 210 flags: STMT_END_F


-vv输出
### UPDATE `test`.`testnull2`
### WHERE
###   @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
###   @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
###   @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
### SET
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2=NULL /* INT meta=60 nullable=1 is_null=1 */
###   @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */


分解:
--event header 部分就不解析了table id 210,
  --hexdump也明确的解析了,不理解参考前面的文章
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      185 24 0e a1 58   1f   e5 6b 01 00   34 00 00 00   b9 01 00 00   00 00
--fixed data
d2 00 00 00 00 00:表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Update_rows: table id 210  
                   小端显示
01 00:保留
02 00:m_extra_row_data,这部分是我看源码找到的。
--variable data part
03:表中字段个数,当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */    
ff:update专用和上面一致


----update前印象数据:
fd: 11111101 代表字段@1=NULL和@3=NULL,但是字段@2不为空这和mysqlbinlog解析的一致
    @1=NULL /* type=3 meta=0 nullable=1 is_null=1 */
    @2='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
    @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
04:var 长度04 就是数据'test'的长度为4,这个也就是@2='test'事update的前印象
74 65 73 74:字符串'test'


----update后印象数据(update 专用):
fa:11111010,@2=NULL,但是修改后@1和@3不为空和mysqlbinlog解析一致
    @1=2 /* INT meta=0 nullable=1 is_null=0 */
    @2=NULL /* INT meta=60 nullable=1 is_null=1 */
    @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */    
02 00 00 00 :也就是数据2也是@1=2也就是update的后印象,小端显示
04: var 长度04 就是数据'test'的长度为4,也就是
74 65 73 74:字符串'test'也是@3='test'也就是update的后印象


1d 59 c0 21:CRC32校验




然后来看delete event
二进制解析
# at 667
#170213  9:38:50 server id 93157  end_log_pos 712 CRC32 0x055741c1 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      29b 2a 0e a1 58   20   e5 6b 01 00   2d 00 00 00   c8 02 00 00   00 00
#      2ae d2 00 00 00 00 00 01 00  02 00 03 ff fa 02 00 00 |................|
#      2be 00 04 74 65 73 74 c1 41  57 05                   |..test.AW.|
#       Delete_rows: table id 210 flags: STMT_END_F




-vv输出
### DELETE FROM `test`.`testnull2`
### WHERE
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
###   @2=NULL /* INT meta=60 nullable=1 is_null=1 */
###   @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */


分解:
--event header 部分就不解析了table id 210,
  --hexdump也明确的解析了,不理解参考前面的文章
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      185 24 0e a1 58   1f   e5 6b 01 00   34 00 00 00   b9 01 00 00   00 00
--fixed data
d2 00 00 00 00 00:表ID就是./infobin中的TABLE_ID:210 也是mysqlbinlog中的Delete_rows: table id 210 
                   小端显示
01 00:保留
02 00:m_extra_row_data,这部分是我看源码找到的。
--variable data part
03:表中字段个数,当然我建表就是3个字段
ff: 源码描述为 m_cols; /* Bitmap denoting columns available */    


fa: 11111010 代表字段@2=NULL,但是字段@1 @3不为空这和mysqlbinlog解析的一致
    @1=2 /* INT meta=0 nullable=1 is_null=0 */
    @2=NULL /* INT meta=60 nullable=1 is_null=1 */
    @3='test' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
02 00 00 00: int 4字节数据 2及@1=2 小端显示
04:var 长度04 就是数据'test'的长度为4,这个也就是@3='test'
74 65 73 74:字符串'test'
c1 41 57 05:crc32 校验


至此UPDATE_ROW_EVENT和DELETE_ROWS_EVENT解析完毕


后记:
1、在UPDATE_ROW_EVENT/DELETE_ROWS_EVENT/WRITE_ROWS_EVENT中存在一个字段值是否为空的位图,如前面所说
   然后紧跟了字段数据,这样根据位图就能确定出那些字段为NULL,而实际存储的值中并不包含NULL字段的数据
   因为它没有数据,同样也为了减少存储空间的使用,这种技术在数据库技术中大量使用,在INNODB PAGES中也
   是用到了。
2、很多闪回工具都依赖了binlog中能够记录了需要的所有信息,我们也看到了update还记录前后印象的值,那么
   也为闪回提供了条件,但是binlog_row_image会影响它的记录方式具体参考官方手册,但是它可以节约空间。    
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN:指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询,帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标,如 `id`、`select_type`、`table`、`type`、`key` 等,并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例,展示了如何通过创建合适索引和调整查询语句来提升查询性能。
291 9
|
3天前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
2月前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
107 2
|
2月前
|
存储 关系型数据库 MySQL
double ,FLOAT还是double(m,n)--深入解析MySQL数据库中双精度浮点数的使用
本文探讨了在MySQL中使用`float`和`double`时指定精度和刻度的影响。对于`float`,指定精度会影响存储大小:0-23位使用4字节单精度存储,24-53位使用8字节双精度存储。而对于`double`,指定精度和刻度对存储空间没有影响,但可以限制数值的输入范围,提高数据的规范性和业务意义。从性能角度看,`float`和`double`的区别不大,但在存储空间和数据输入方面,指定精度和刻度有助于优化和约束。
291 5
|
2月前
|
SQL 存储 缓存
MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。
|
3月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
124 2
|
4月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
98 1
|
2月前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是"将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。创建型模式分为5种:单例模式、工厂方法模式抽象工厂式、原型模式、建造者模式。
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
2月前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
2月前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析

推荐镜像

更多