解析MYSQL BINLOG 二进制格式(2)--FORMAT_DESCRIPTION_EVENT

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 原创:转载请说明出处谢谢! 上接 http://blog.itpub.net/7728585/viewspace-2133188/ 参考源: 1、源码log_event.
原创:转载请说明出处谢谢!

上接
http://blog.itpub.net/7728585/viewspace-2133188/

参考源:
1、源码log_event.h log_event.cc
2、internals-en.epub

class:Format_description_log_event
event:FORMAT_DESCRIPTION_EVENT

mysql 5.0后所有的binlog 文件都是以FORMAT_DESCRIPTION_EVENT(FED) event开始的,其typecode=15
及0X0F
它的格式为:

1、fixed data part
   2 bytes:binlog 的格式版本,我们看到5.6,5.7肯定都是v4
   50 bytes:这是一个固定50字节的字符串,显示了mysql server的版本,用0X00补足
             也就是第一个0X00表示结尾
   4 bytes: 这4个字节文档上说是冗余的,在event header显示,这里看到全是0X00
   1 bytes:这个字节直接说明了我们event header的长度,V4为19
   var-size:这些字节由已经定义的event的个数定义5.6,5.7为40个,也就是40个字节
             说明了他们fixed data(posted header)的长度
2、variable data
    无
             
我们来解析一个实际的二进制格式文件


00000000  fe 62 69 6e bc df 98 58  0f 01 00 00 00 77 00 00  |.bin...X.....w..|
00000010  00 7b 00 00 00 00 00 04  00 35 2e 37 2e 31 34 2d  |.{.......5.7.14-|
00000020  37 2d 64 65 62 75 67 2d  6c 6f 67 00 00 00 00 00  |7-debug-log.....|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 13  |................|
00000050  38 0d 00 08 00 12 00 04  04 04 04 12 00 00 5f 00  |8............._.|
00000060  04 1a 08 00 00 00 08 08  08 02 00 00 00 0a 0a 0a  |................|
00000070  2a 2a 00 12 34 00 01 55  88 2c 87 


mysqlbinlog输出为:
# at 4
#170207  4:42:36 server id 1  end_log_pos 123 CRC32 0x872c8855  Start: binlog v 4, server v 5.7.14-7-debug-log created 170207  4:42:36
BINLOG '
vN+YWA8BAAAAdwAAAHsAAAAAAAQANS43LjE0LTctZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AVWILIc=
'/*!*/;

fe 62 69 6e:binlog开头魔法数 4字节
event header
bc df 98 58:timestamp,小端显示,及0X5898DFBC十进制1486413756,用命令
                  [root@testmy mysqld.1]# date -d'@1486413756'
                  Tue Feb  7 04:42:36 CST 2017
                   可以看见时间和mysqbinlog解析的一致4:42:36
0f:event_type为15
01 00 00 00:service_id,小端显示 0X00000001及1
                    mysql> show variables like 'server_id';
                   +---------------+-------+
                   | Variable_name | Value |
                   +---------------+-------+
                   | server_id     | 1     |
                   +---------------+-------+
                  和mysqlbinlog中的server id 1也是一致的
77 00 00 00:event长度及0X00000077及119,刚好是下一个event 123-4(魔法数)=119
7b 00 00 00:下一个event位置0X0000007b及123,和mysqlbinlog解析的end_log_pos 123一致
00 00:flags,如果为0X0001那么会在MYSQLBINLOG输出中报一个警告说本binlog没有关闭
04 00:binlog 版本,小端显示及0X0004,和mysqlbinlog中的解析Start: binlog v 4一致

35 2e 37 2e 31 34 2d 37  2d 64 65 62 75 67 2d 6c 
6f 67 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
00 00 :
这部分就是50字节的字符串了其ASCII值是5.7.14-7-debug-log和mysqlbinlog中的解析
server v 5.7.14-7-debug-log一致

00 00 00 00:冗余的timestamp,全是0X00

13 38 0d 00 08 00 12 00  04 04 04 04 12 00 00 5f 
00 04 1a 08 00 00 00 08  08 08 02 00 00 00 0a 0a 
0a 2a 2a 00 12 34 00 01:
这部分是一个数组,表现了已知的40个event的fixed data(posted header)的长度
打个比方说0a 0a 0a 这里刚好array[30],array[31],array[32](C语言以[0]作为数
组的开始)就是我们最要的
WRITE_ROWS_EVENT
UPDATE_ROWS_EVENT
DELETE_ROWS_EVENT
的fixed data(posted header)的长度0X0A也就是10,以后会详细解释

55 88 2c 87: CRC32校验位,小端显示及0X872C8855和mysqlbinlog中的CRC32 0x872c8855一致

到这里FORMAT_DESCRIPTION_EVENT解析完毕
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
12天前
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志和二进制日志是确保数据库稳定性和可靠性的关键组件。重做日志主要用于事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务;而二进制日志记录SQL语句的逻辑变化,支持数据复制、恢复和审计。两者在写入时机、存储方式及配置参数等方面存在显著差异。
|
3天前
|
存储 关系型数据库 MySQL
double ,FLOAT还是double(m,n)--深入解析MySQL数据库中双精度浮点数的使用
本文探讨了在MySQL中使用`float`和`double`时指定精度和刻度的影响。对于`float`,指定精度会影响存储大小:0-23位使用4字节单精度存储,24-53位使用8字节双精度存储。而对于`double`,指定精度和刻度对存储空间没有影响,但可以限制数值的输入范围,提高数据的规范性和业务意义。从性能角度看,`float`和`double`的区别不大,但在存储空间和数据输入方面,指定精度和刻度有助于优化和约束。
|
22小时前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN:指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询,帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标,如 `id`、`select_type`、`table`、`type`、`key` 等,并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例,展示了如何通过创建合适索引和调整查询语句来提升查询性能。
21 9
|
11天前
|
SQL 存储 缓存
MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。
|
15天前
|
存储 网络协议 算法
【C语言】进制转换无难事:二进制、十进制、八进制与十六进制的全解析与实例
进制转换是计算机编程中常见的操作。在C语言中,了解如何在不同进制之间转换数据对于处理和显示数据非常重要。本文将详细介绍如何在二进制、十进制、八进制和十六进制之间进行转换。
27 5
|
29天前
|
关系型数据库 MySQL 数据库
【赵渝强老师】MySQL的binlog日志文件
MySQL的binlog日志记录了所有对数据库的更改操作(不包括SELECT和SHOW),主要用于主从复制和数据恢复。binlog有三种模式,可通过设置binlog_format参数选择。示例展示了如何启用binlog、设置格式、查看日志文件及记录的信息。
|
1月前
|
监控 关系型数据库 MySQL
MySQL自增ID耗尽应对策略:技术解决方案全解析
在数据库管理中,MySQL的自增ID(AUTO_INCREMENT)属性为表中的每一行提供了一个唯一的标识符。然而,当自增ID达到其最大值时,如何处理这一情况成为了数据库管理员和开发者必须面对的问题。本文将探讨MySQL自增ID耗尽的原因、影响以及有效的应对策略。
104 3
|
1月前
|
存储 关系型数据库 MySQL
MySQL 字段类型深度解析:VARCHAR(50) 与 VARCHAR(500) 的差异
在MySQL数据库中,`VARCHAR`类型是一种非常灵活的字符串存储类型,它允许存储可变长度的字符串。然而,`VARCHAR(50)`和`VARCHAR(500)`之间的差异不仅仅是长度的不同,它们在存储效率、性能和使用场景上也有所不同。本文将深入探讨这两种字段类型的区别及其对数据库设计的影响。
45 2
|
3月前
|
canal 消息中间件 关系型数据库
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
793 4
|
4月前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
506 2

推荐镜像

更多