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

本文涉及的产品
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS Agent(兼容Hermes Agent),2核4GB
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介: 原创:转载请说明出处谢谢! 上接 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解析完毕
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
8月前
|
Ubuntu 关系型数据库 MySQL
MySQL二进制包安装
本文详细介绍了在多种Linux系统上通过二进制包安装MySQL 8.0和8.4版本的完整过程,涵盖用户创建、glibc版本匹配、程序解压、环境变量配置、初始化数据库及服务启动等步骤,并提供支持多发行版的一键安装脚本,助力高效部署MySQL环境。
1361 4
MySQL二进制包安装
|
9月前
|
SQL 运维 关系型数据库
深入探讨MySQL的二进制日志(binlog)选项
总结而言,对MySQL binlogs深度理解并妥善配置对数据库运维管理至关重要;它不仅关系到系统性能优化也是实现高可靠性架构设计必须考虑因素之一。通过精心规划与周密部署可以使得该机能充分发挥作用而避免潜在风险带来影响。
307 6
|
10月前
|
存储 SQL 关系型数据库
MySQL中binlog、redolog与undolog的不同之处解析
每个都扮演回答回溯与错误修正机构角色: BinLog像历史记载员详细记载每件大大小小事件; RedoLog则像紧急救援队伍遇见突發情況追踪最后活动轨迹尽力补救; UndoLog就类似时间机器可倒带历史让一切归位原始样貌同时兼具平行宇宙观察能让多人同时看见各自期望看见历程而互不干扰.
574 9
|
11月前
|
存储 SQL 关系型数据库
MySQL的Redo Log与Binlog机制对照分析
通过合理的配置和细致的管理,这两种日志机制相互配合,能够有效地提升MySQL数据库的可靠性和稳定性。
363 10
|
SQL 监控 关系型数据库
MySQL日志分析:binlog、redolog、undolog三大日志的深度探讨。
数据库管理其实和写小说一样,需要规划,需要修订,也需要有能力回滚。理解这些日志的作用与优化,就像把握写作工具的使用与运用,为我们的数据库保驾护航。
915 23
|
Oracle 关系型数据库 MySQL
Oracle linux 8 二进制安装 MySQL 8.4企业版
Oracle linux 8 二进制安装 MySQL 8.4企业版
618 1
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog(二进制日志)功能及其使用方法。Binlog 记录了数据库的所有数据变更操作,如 INSERT、UPDATE 和 DELETE,对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容,并解析了常见的事件类型,包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等,帮助用户掌握数据库变化历史,提升维护和排障能力。
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
284 4
|
SQL 存储 关系型数据库
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
1958 0
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志和二进制日志是确保数据库稳定性和可靠性的关键组件。重做日志主要用于事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务;而二进制日志记录SQL语句的逻辑变化,支持数据复制、恢复和审计。两者在写入时机、存储方式及配置参数等方面存在显著差异。
370 6

推荐镜像

更多