【文档】七、Mysql Binlog不同事件类型的事件内容

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:

下面主要讲述了每个类型的事件中的固定和可变部分的数据。

Start_log_event_v3/START_EVENT_V3

这个事件出现在v1或v3的binlog文件的开头部分。对于4.0和4.1版本的Mysql,这个事件只是被写在服务启动后的第一个binlog文件中,到达一定的条件后,会产生新的日志文件,但是新的日志文件中不包含这个事件。对于所有的Mysql5.0及以上版本,每个日志文件都会以FORMAT_DESCRIPTION_EVENT开头。

固定数据部分:

  • 2字节,binlog格式版本。对3.23版本为1,4.0和4.1版本为3(对5.0及以上版本,FORMAT_DESCRIPTION_EVENT会替代START_EVENT_V3)
  • 50字节,Mysql服务器版本(例如:4.0.14-debug-log),后面跟着0x00。
  • 4字节,事件创建的时间戳,精确到秒。(也就是这个文件创建的时间戳)。这个值是多余的,因为头中有相同的字段。

可变数据部分:

Query_log_event/QUERY_EVENT

固定数据部分:

  • 4字节。发起这个语句的线程id,对于临时表来说是必须的。这也有助于DBA知道谁在master上干了啥。
  • 4字节。语句执行的时长,单位为秒。只对于DBA的监控有用。
  • 1字节。语句执行对应的数据库名称的长度。名称在可变数据部分。
  • 2字节。在master执行语句的错误码。错误码定义在include/mysqld_error.h文件中。0表示没有错误。
  • 2字节(v1和v3中不存在)。状态变量长度。

可变数据部分:

  • 大于等于0的状态变量(v1、v3中不存在)。每个状态变量包含一个字节码,标识存储变量,后面跟着变量的值。
  • 默认数据库名
  • SQL语句。slave知道变量中其他字段的长度,所以通过减法计算,可以知道语句的长度。

下面的列表提供了每个变量的基本信息:

  • Q_FLAGS2_CODE=0。值为一个4字节的位字段。这个变量只会在5.0中写入。
  • Q_SQL_MODE_CODE = 1. 他是一个每一位代表SQL_MODE中的一个值,参考最后源码的解释
  • Q_CATALOG_CODE = 2. 只在MYSQL 5.0.0到5.0.3使用不考虑
  • Q_AUTO_INCREMENT = 3. 2 bytes非负整数用于表示参数auto_increment_increment和auto_increment_offset,这个只会在auto_increment大于1的时候出现
  • Q_CHARSET_CODE = 4. 6 bytes用于表示character_set_client,collation_connection和collation_server参数(totally 2+2+2=6 bytes)参考最后源码解释
  • Q_TIME_ZONE_CODE = 5. 用于描述time zone信息
  • Q_CATALOG_NZ_CODE = 6. 用于描述catalog name,长度占用一个字节,随后这个值为std
  • Q_LC_TIME_NAMES_CODE = 7. 2 bytes 非负整数,只有当lc_time_names不设置为en_US的时候使用
  • Q_CHARSET_DATABASE_CODE = 8. 2 bytes 非负整数为collation_database系统变量,5.7源码解释说这部分新版本不一定使用。
  • Q_TABLE_MAP_FOR_UPDATE_CODE = 9.

Stop_log_event/STOP_EVENT

这个事件会在以下情况下写入:

  • master挂掉时会写到binlog中
  • slave挂掉时会向relay log中写入或者RESET SLAVE命令执行时。

固定数据部分:

可变数据部分:

Rotate_log_event/ROTATE_EVENT

当binlog的文件大小超过阈值时,这个事件会写到binlog的结尾处,指向下一个binlog文件序列。这个事件可以让slave知道下一个binlog文件的名字,以便它去接收。

ROTATE_EVENT是在master本地产生并写入binlog中的。当FLUSH LOGS命令执行时或收到master的ROTATE_EVENT时,slave会写到他的relay log中。

固定数据部分:

  • 8字节。下个日志文件的第一个事件的位置。经常包含数字4(表示下个binlog的下个事件从位置4开始)。这个字段在v1中不存在。可以推测,这个值是4。
  • 可变数据部分:
  • 下个binlog文件的名字。文件名不是以null结尾的,他的长度是事件长度-固定数据长度。

Intvar_log_event/INTVAR_EVENT

固定数据部分:

可变数据部分:

  • 1字节。表示参数类型,LAST_INSERT_ID_EVENT=1或者INSERT_ID_EVENT=2。
  • 8字节。无符号整数,表示LAST_INSERT_ID()调用的值或者AUTO_INCREMENT列的值。

Load_log_event/LOAD_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Slave_log_event/SLAVE_EVENT

从没用过这个事件。

Create_file_log_event/CREATE_FILE_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Append_block_log_event/APPEND_BLOCK_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Execute_log_event/EXEC_LOAD_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Delete_file_log_event/DELETE_FILE_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Load_log_event/NEW_LOAD_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Rand_log_event/RAND_EVENT

RAND()函数会产生一个随机数。这个事件包含两个种子值,用于产生随机数。

固定数据部分:

可变数据部分:

  • 8字节。第一个种子的值。
  • 8字节。第二个种子的值。

User_var_log_event/USER_VAR_EVENT

固定数据部分:

可变数据部分:

  • 4字节。用户参数名的长度。
  • 用户参数名。
  • 1字节。如果参数值是SQL的NULL值,不为零,否则为0.如果这个字节是0,会包含下面的内容。
  • 1字节。用户参数类型。STRING_RESULT=0,REAL_RESULT=1,INT_RESULT=2,ROW_RESULT=3,DECIMAL_RESULT=4。
  • 4字节。用户参数的编码集代表的数字。
  • 4字节。用户参数值的大小。
  • 可变大小。对于一个字符串的变量,这是字符串。对于浮点数或整数,这个值是8字节。对于十进制的数,值为一个封包值。

Format_description_log_event/FORMAT_DESCRITION_EVENT

这个在之前讲过很多了,是v4版本的格式描述事件。

固定数据部分:

  • 2字节。binlog格式版本,对于5.0及以上版本,是4.
  • 50字节。Mysql服务器版本,右边带着0x00。
  • 4字节。事件创建的时间戳。多余的参数,和头中的时间戳重复。
  • 1字节。头长度。当前的值为19.
  • 可变长度。表示所有事件类型的头长度信息的数组。

可变数据部分:

  • 空。

Xid_log_event/XID_EVENT

对于支持XA事务的存储引擎来说,一个XID事件是在改变一个或多个表数据的事务提交时产生的。严格的讲,这个事件是在thd->transaction.xid_state.xid.get_my_xid()方法返回不为0时,使用的。

下面举例说明如何产生一个XID事件(无论是否开启innodb_support_xa):

CREATE TABLE t1 (a INT) ENGINE = INNODB;
START TRANSACTION;
INSERT INTO t1 VALUES (1);
COMMIT;

固定数据部分:

可变数据部分:

  • 8字节,XID事务号

Begin_load_query_log_event/BEGIN_LOAD_QUERY_EVENT

用于LOAD DATA INFILE语句中。这块用的比较少,先跳过。

Table_map_log_event/TABLE_MAP_EVENT

从5.1.5开始用于基于行的binlog文件。

固定数据部分:

  • 6字节,表id
  • 2字节,保留字段。

可变数据部分:

  • 1字节,数据库名长度
  • 可变大小。数据库名(以null结尾)
  • 1字节,表名长度
  • 可变大小,表名(以null结尾)
  • 封包整数,表中列的数量
  • 可变大小,列类型的数组,每一列一个字节。
  • 封包整数,元数据块大小
  • 可变大小,元数据块
  • 可变大小,位字段,表示每一列是否可以为空,每列一比特。对这个字段,对于一个N列的存储大小为INT((N+7)/8)字节。

Write_rows_log_event_old/PRE_GA_WRITE_ROWS_EVENT

用于5.1.5到5.1.17版本的基于行的binlog,Write_rows_log_event/WRITE_ROWS_EVENT的老版本实现。结构和最新的版本类似。

Update_rows_log_event_old/PRE_GA_UPDATE_ROWS_EVENT

用于5.1.5到5.1.17版本的基于行的binlog,Update_rows_log_event/UPDATE_ROWS_EVENT的老版本实现。结构和最新的版本类似。

Delete_rows_log_event_old/PRE_GA_DELETE_ROWS_EVENT

用于5.1.5到5.1.17版本的基于行的binlog,Delete_rows_log_event/DELETE_ROWS_EVENT的老版本实现。结构和最新的版本类似。

Write_rows_log_event/WRITE_ROWS_EVENT

用于5.1.18版本的基于行的binlog。

固定数据部分:

  • 6字节,表id
  • 2字节,保留字段

可变数据部分:

  • 封包整数。表中列的数量
  • 可变大小,位字段,表示每一列是否使用到,每列一个比特。对于这个字段,对于一个N列的表需要的存储空间为INT((N+7)/8)字节。
  • 可变大小(只用于UPDATE_ROWS_LOG_EVENT)。
  • 可变大小,0列或多列的序列,结尾由时间的大小决定,每一列是下面的格式:

    • 可变大小。位字段,表示每列的字段是否为空。只有在第二个字段中使用到的变量数据部分才会展示在这里。如果第二个字段包含N个比特,当前字段需要的空间为INT((N+7)/8)字节。
    • 可变大小。列映射,包含表中所有列的值。这个字段只会列出使用到的字段。
    • 每种值的格式定义在log_event.cc的log_event_value()函数中。
    • (仅对UPDATE_ROWS_EVENT)前面的2个字段是重复的。

Update_rows_log_event/UPDATE_ROWS_EVENT

用于5.1.18版本的基于行的binlog。见WRITE_ROWS_EVENT的描述。

Delete_rows_log_event/DELETE_ROWS_EVENT

用于5.1.18版本的基于行的binlog。见WRITE_ROWS_EVENT的描述。

Incident_log_event/INCIDENT_EVENT

固定数据部分:

  • 1字节,故障号。
  • 1字节,消息长度。

可变数据部分

  • 如果有的话,是故障信息

故障号定义在rpl_constant.h中。当前唯一使用到的是INCIDENT_LOST_EVENTS,这个表示在复制过程中可能有丢包,需要重新进行同步。

Heartbeat_log_event/HEARTBEAT_LOG_EVENT

这个事件是由master发给slave的,让slave知道master还活着。这类事件不会再binlog或relay log中出现。他们由master的dump事件线程产生,然后直接发给了slave。slave收到后,校验事件内容后,直接抛弃这个事件,而不会写到relay log中。

固定数据部分

可变数据部分

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2月前
|
canal 消息中间件 关系型数据库
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
654 4
|
15天前
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志(Redo Log)和二进制日志(Binary Log)是两种重要的日志系统。重做日志主要用于保证事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务更改。二进制日志则记录了数据库的所有逻辑变化操作,用于数据的复制、恢复和审计。两者在写入时机、存储方式、配置参数和使用范围上有所不同,共同确保了数据库的稳定性和可靠性。
|
1月前
|
SQL 关系型数据库 MySQL
MySQL中的 where 1=1会不会影响性能?看完官方文档就悟了!
本文探讨了在Mybatis中使用`where 1=1`进行动态SQL拼接是否会影响性能。通过MySQL官方资料和实际测试表明,`where 1=1`在MySQL 5.7及以上版本中会被优化器优化,因此对性能影响不大。文中详细对比了`where 1=1`与`<where>`标签的使用方法,并建议根据MySQL版本和团队需求选择合适的方式。最后,推荐查找官方资料以确保技术路线正确。
42 4
|
2月前
|
消息中间件 canal 关系型数据库
Maxwell:binlog 解析器,轻松同步 MySQL 数据
Maxwell:binlog 解析器,轻松同步 MySQL 数据
315 11
|
2月前
|
关系型数据库 MySQL
mysql 官网文档
mysql官网使用指南
mysql 官网文档
|
30天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
71 0
|
3月前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
388 2
|
3月前
|
SQL 关系型数据库 MySQL
【MySQL】根据binlog日志获取回滚sql的一个开发思路
【MySQL】根据binlog日志获取回滚sql的一个开发思路
|
3月前
|
关系型数据库 MySQL Shell
MySQL回滚脚本: 误操作delete binlog回滚shell脚本
MySQL回滚脚本: 误操作delete binlog回滚shell脚本
|
3月前
|
关系型数据库 MySQL 数据库
MySQL回滚工具:binlog 闪回工具 MyFlash工具
MySQL回滚工具:binlog 闪回工具 MyFlash工具
下一篇
无影云桌面