解析MYSQL BINLOG二进制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
公共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 
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二进制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT  
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二进制格式(7)--Xid_log_event/XID_EVENT 


这部分在文档interal中并没有找到解析,但是通过翻阅源码class定义找到一些定义
部分可知,部分未知,如果以后找到会补上,如果有误请指出

class:Gtid_log_event
event:GTID_LOG_EVENT
event_code:33

class:Gtid_log_event
event:ANONYMOUS_GTID_LOG_EVENT
event_code:34


class:Previous_gtids_log_event
event:PREVIOUS_GTIDS_LOG_EVENT
event_code:35


首先是GTID_LOG_EVENT和ANONYMOUS_GTID_LOG_EVENT
他们源于一个class
(
ANONYMOUS: gtid_mode [ON ON_PERMISSIVE]
非ANONYMOUS:gtid_mode [OFF OFF_PERMISSIVE]
)


只是ANONYMOUS基本没有填充值,我们来看看源码中对他们的定义:
位置在:
Control_events.h 中


protected:
  static const int ENCODED_FLAG_LENGTH= 1;
  static const int ENCODED_SID_LENGTH= 16;// Uuid::BYTE_LENGTH;
  static const int ENCODED_GNO_LENGTH= 8;
  /// Length of typecode for logical timestamps.
  static const int LOGICAL_TIMESTAMP_TYPECODE_LENGTH= 1;
  /// Length of two logical timestamps.
  static const int LOGICAL_TIMESTAMP_LENGTH= 16;
  // Type code used before the logical timestamps.
  static const int LOGICAL_TIMESTAMP_TYPECODE= 2;
  gtid_info gtid_info_struct;
  Uuid Uuid_parent_struct;
public:
  /// Total length of post header
  static const int POST_HEADER_LENGTH=
    ENCODED_FLAG_LENGTH                 /* flags */ 1
    ENCODED_SID_LENGTH                  /* SID length */ 16
    ENCODED_GNO_LENGTH                  /* GNO length */ 8
    LOGICAL_TIMESTAMP_TYPECODE_LENGTH  /* length of typecode */ 1
    LOGICAL_TIMESTAMP_LENGTH;           /* length of two logical timestamps */ 16
    
我们可以明确看出GITD存储的地方ENCODED_SID_LENGTH 16,ENCODED_GNO_LENGTH 8
 LOGICAL_TIMESTAMP_LENGTH 两个8字节分别表示 last_committedsequence_number
,在ANONYMOUS GTID除了 last_committed sequence_number其他字节为0X00
 /* Binlog-specific logical timestamps. */
  /*
    Store for the transaction's commit parent sequence_number.
    The value specifies this transaction dependency with a "parent"
    transaction.
    The member is assigned, when the transaction is about to commit
    in binlog to a value of the last committed transaction's sequence_number.
    This and last_committed as numbers are kept ever incremented
    regardless of binary logs being rotated or when transaction
    is logged in multiple pieces.
    However the logger to the binary log may convert them
    according to its specification.
  */
  int64 last_committed;
  /*
    The transaction's private logical timestamp assigned at the
    transaction prepare phase. The timestamp enumerates transactions
    in the binary log. The value is gained through incrementing (stepping) a
    global clock.
    Eventually the value is considered to increase max_committed_transaction
    system clock when the transaction has committed.
  */
  int64 sequence_number; 


来具体解析一个:
Gtid_log_event/GTID_LOG_EVENT
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#       c2 05 01 9d 58   21   e5 6b 01 00   41 00 00 00   03 01 00 00   00 00
#       d5 01 4a 6f 2a 67 5d 87 11  e6 a6 bd 00 0c 29 a8 79 |.Jo.g..........y|
#       e5 a3 f0 43 0f 00 00 00 00  00 02 00 00 00 00 00 00 |..C.............|
#       f5 00 00 01 00 00 00 00 00  00 00 7d 32 90 b4       |...........2..|
#       GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '4a6f2a67-5d87-11e6-a6bd-000c29a879a3:1000432'/*!*/;


01:flags未知                                                              
4a 6f 2a 67 5d 87 11 e6 a6 bd 00 0c 29 a8 79 a3: 4a6f2a67-5d87-11e6-a6bd-000c29a879a3
f0 43 0f 00 00 00 00 00 : 小端显示0X0f43f0,1000432                                       
02:length of typecode未知 
00 00 00 00 00 00 00 00: last_committed 
01 00 00 00 00 00 00 00: sequence_number
7d 32 90 b4 :CRC32校验


那看一个ANONYMOUS的
# at 194
#170214  4:12:30 server id 93157  end_log_pos 259 CRC32 0x0901e014 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#       c2 2e 13 a2 58   22   e5 6b 01 00   41 00 00 00   03 01 00 00   00 00
#       d5 01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
#       e5 00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00 |................|
#       f5 00 00 01 00 00 00 00 00  00 00 14 e0 01 09       |..............|
#       GTID [commit=yes]
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;




除了 last_committed  和 sequence_number作为组提交的标志,其他位基本都为0及没有gtid生成


PREVIOUS_GTIDS_LOG_EVENT:用于表示上一个binlog最后一个gitd的位置,每个binlog只有一个


# at 123
#170214  4:46:24 server id 93157  end_log_pos 194 CRC32 0xd10caea6 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#       7b 20 1b a2 58   23   e5 6b 01 00   47 00 00 00   c2 00 00 00   80 00
#       8e 01 00 00 00 00 00 00 00  4a 6f 2a 67 5d 87 11 e6 |........Jo.g....|
#       9e a6 bd 00 0c 29 a8 79 a3  01 00 00 00 00 00 00 00 |......y.........|
#       ae 01 00 00 00 00 00 00 00  05 44 0f 00 00 00 00 00 |.........D......|
#       be a6 ae 0c d1                                      |....|
#       Previous-GTIDs
# 4a6f2a67-5d87-11e6-a6bd-000c29a879a3:1-1000452


关于这部分解析位置特别是1-1000452的解析。如果以后知道了补上
只是在源码注释中找到:
/**
  @class Previous_gtids_event


  @section Previous_gtids_event_binary_format Binary Format


  The Post-Header for this event type is empty.  The Body has two
  components:

 
Name Format Description
buf unsigned char array It contains the Gtids executed in the
        last binary log file.
buf_size 4 byte integer Size of the above buffer

*/
但是不知道解析方法。




其他EVENT:
这部分列出的event可以直接参考internals 20章 比较简单就不用再开文章写了
Stop_log_event/STOP_EVENT(03):数据库关闭,或者SLAVE执行了reset slave。
Rotate_log_event/ROTATE_EVENT(04):binlog切换事件,比如超过参数设置。如果服务器CRASH不会记录
Intvar_log_event/INTVAR_EVENT(05):和自增字段有关
Rand_log_event/RAND_EVENT(13):和RAND()函数相关
还有很多和load data infile 有关的event这里就不考虑了。因为平时我们用load data infile 并不多,这里主要考虑
和事物有关的各种的event




    


相关实践学习
如何快速连接云数据库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 语句的具体方法。通过实战案例,展示了如何通过创建合适索引和调整查询语句来提升查询性能。
324 9
|
7天前
|
存储 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
|
5天前
|
SQL 缓存 关系型数据库
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
|
17天前
|
监控 Oracle 关系型数据库
Mysql、Oracle审计日志的开启
通过上述步骤,可以在 MySQL 和 Oracle 数据库中启用和配置审计日志。这些日志对于监控数据库操作、提高安全性和满足合规性要求非常重要。确保正确配置审计参数和策略,定期查看和分析审计日志,有助于及时发现并处理潜在的安全问题。
36 11
|
1月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
MySQL事务日志-Undo Log工作原理分析
|
2月前
|
SQL 存储 关系型数据库
Mysql并发控制和日志
通过深入理解和应用 MySQL 的并发控制和日志管理技术,您可以显著提升数据库系统的效率和稳定性。
164 10
|
2月前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
113 3
|
2月前
|
存储 关系型数据库 MySQL
double ,FLOAT还是double(m,n)--深入解析MySQL数据库中双精度浮点数的使用
本文探讨了在MySQL中使用`float`和`double`时指定精度和刻度的影响。对于`float`,指定精度会影响存储大小:0-23位使用4字节单精度存储,24-53位使用8字节双精度存储。而对于`double`,指定精度和刻度对存储空间没有影响,但可以限制数值的输入范围,提高数据的规范性和业务意义。从性能角度看,`float`和`double`的区别不大,但在存储空间和数据输入方面,指定精度和刻度有助于优化和约束。
321 5
|
3月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
129 2
|
2月前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是"将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。创建型模式分为5种:单例模式、工厂方法模式抽象工厂式、原型模式、建造者模式。
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析