专栏首页mysql-dbamysql二进制日志文件中同一事务的事件时间点会乱序验证
原创

mysql二进制日志文件中同一事务的事件时间点会乱序验证

验证过程:

开启一个显式update事务,在事务操作中间进行短暂的停留,然后观察解析的二进制日志

mysql> flush logs;  -- 切换日志
Query OK, 0 rows affected (0.02 sec)

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000008 |      195 |              |                  | 3d1b92a0-b919-11eb-87db-56c8a95977d1:1-32 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

mysql> begin;select now();   -- 开启事务
Query OK, 0 rows affected (0.00 sec)

+---------------------+
| now()               |
+---------------------+
| 2021-06-10 10:34:49 |
+---------------------+
1 row in set (0.00 sec)

mysql> update test set name='wwwwxxx' where id=2;select now();  --停留一段时间执行update,并记录时间
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

+---------------------+
| now()               |
+---------------------+
| 2021-06-10 10:38:42 |
+---------------------+
1 row in set (0.00 sec)

mysql> commit;select now();  -- 停留一段时间并进行commit
Query OK, 0 rows affected (0.00 sec)

+---------------------+
| now()               |
+---------------------+
| 2021-06-10 10:39:47 |
+---------------------+
1 row in set (0.00 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)

解析binlog日志:

/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000008 > 8.sql

#210610 10:39:47 server id 2223306  end_log_pos 274 CRC32 0x4b5be137    GTID    last_committed=0
sequence_number=1       rbr_only=yes    original_committed_timestamp=1623292787365217   
immediate_commit_timestamp=1623292787365217     transaction_length=380
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1623292787365217 (2021-06-10 10:39:47.365217 CST)
# immediate_commit_timestamp=1623292787365217 (2021-06-10 10:39:47.365217 CST)
/*!80001 SET @@session.original_commit_timestamp=1623292787365217*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= '3d1b92a0-b919-11eb-87db-56c8a95977d1:33'/*!*/;
# at 274
#210610 10:38:42 server id 2223306  end_log_pos 360 CRC32 0x3204f1cf    Query   thread_id=14    
exec_time=0     error_code=0
SET TIMESTAMP=1623292722/*!*/;
SET @@session.pseudo_thread_id=14/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, 
@@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 360
#210610 10:38:42 server id 2223306  end_log_pos 425 CRC32 0xe6c95c11    Rows_query
# update test set name='wwwwxxx' where id=2
# at 425
#210610 10:38:42 server id 2223306  end_log_pos 483 CRC32 0x4820792f    Table_map: `testdb`.`test` 
mapped to number 87
# at 483
#210610 10:38:42 server id 2223306  end_log_pos 544 CRC32 0x53d71b03    Update_rows: table id 87 
flags: STMT_END_F
### UPDATE `testdb`.`test`
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='rowlog' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
### SET
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='wwwwxxx' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
# at 544
#210610 10:39:47 server id 2223306  end_log_pos 575 CRC32 0x2c6dbb06    Xid = 67
COMMIT/*!*/;
# at 575

从binlog日志可以看出一个事务的事件,从上到下为:

Gtid_log_event: binglog记录时间 21061010:39:47 事务的commit时间

Query_log_event: binglog记录时间21061010:38:42 update执行时间

Rows_query_log_event: binglog记录时间21061010:38:42

Table_map_event: binglog记录时间21061010:38:42

Update_rows_log_event: binglog记录时间21061010:38:42

Xid_event: binglog记录时间 21061010:39:47 事务的commit时间

所以从binlog日志看到时间Gtid_log_event在前面大于后面的事件时间了。

Gtid_log_event和Xid_event事件是在事务commit时的时间

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Oracle/云MySQL/MsSQL“大迁移”真相及最优方案

    抛开业务逻辑的因素,根据不同的版本、不同平台、不同停机时间需求,有不同的可选路径决定迁移方

    数据和云
  • MySQL 复制原理详解

    mysql作为一个开源的数据库,有着广泛的应用。本文主要讲述了mysql复制的原理,以及异步复制,同步复制和并行复制。

    云加社区
  • Oracle/云MySQL/MsSQL“大迁移”真相及最优方案

    抛开业务逻辑的因素,根据不同的版本、不同平台、不同停机时间需求,有不同的可选路径决定迁移方

    数据和云01
  • 一小时让你彻底理解 MySQL

    在写本文章开始之前我给大家说下,根据个人学历理解记录的笔记,如果有什么问题可以关注、联系我们一起讨论。本人还是建议大家多多学习体系的技术。博客不会讲解太细。

    苏州程序大白
  • Mysql备份系列(1)--备份方案总结性梳理

    mysql数据库备份有多么重要已不需过多赘述了,废话不多说!以下总结了mysql数据库的几种备份方案: 一、binlog二进制日志通常作为备份的重要资源,所以再...

    洗尽了浮华
  • MySQL基础概念知多少

    MySQL相关的名词概念还是挺多的,但是常用的也不多,因此将常用的统计整理下,便于回顾:

    luoxn28
  • MySQL崩溃后的数据一致性

    谁也不能保证计算机系统能够永远无故障的执行下去。网络波动、磁盘损坏等现网高频故障,机房掉电、服务器硬件失效等低频却又致命的故障,时刻考验着我们的系统。

    lakezhong
  • MySQL基础篇(07):用户和权限管理,日志体系简介

    在数据库的使用过程中,用户作为访问数据库的鉴权因素,起到非常重要的作用,安装MySQL时会自动生成一个root用户,作为数据库管理员,拥有所有权限。在多用户的应...

    知了一笑
  • 【Mysql 实战】问题分析利器之 binlog

    文章链接:https://mp.weixin.qq.com/s/JOhdZE6ctDI0y53G_qXR8w

    程序员架构进阶
  • MySQL 8 复制(一)——异步复制

    简单说,复制就是将来自一个MySQL数据库服务器(主库)的数据复制到一个或多个MySQL数据库服务器(从库)。传统的MySQL复制提供了一种简单...

    用户1148526
  • 青铜到王者,看看你的MySQL数据库是什么段位,如何提升?

    作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

    数据和云
  • MySQL 8 复制(四)——GTID与复制

    版权声明:本文为博主原创文章,未经博主允许不得转载。 ...

    用户1148526
  • 2021年最新大厂php+go面试题集(四)

    微信公众号:码农编程进阶笔记 关注可获得更多的视频教程及面试技巧。问题或建议,请公众号留言!

    码农编程进阶笔记
  • mysql的"双1设置"-数据安全的关键参数(案例分享)

    mysql的"双1验证"指的是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置,这两个是是控制MySQL 磁盘写...

    洗尽了浮华
  • MySQL 5.7基于GTID及多线程主从复制

    MySQL主从同步是在MySQL主从复制(Master-Slave Replication)基础上实现的,通过设置在Master MySQL上的binlog(使...

    小小科
  • MySQL不会丢失数据的秘密,就藏在它的 7种日志里

    记住! 记住! 记住! 上边这张图,她是MySQL更新数据的基础流程,其中包括redo log、bin log、undo log三种日志间的大致关系,好了闲话少...

    程序员内点事
  • MySQL不会丢失数据的秘密,就藏在它的 7种日志里

    记住! 记住! 记住! 上边这张图,她是MySQL更新数据的基础流程,其中包括redo log、bin log、undo log三种日志间的大致关系,好了闲话少...

    程序员内点事
  • MySQL不会丢失数据的秘密,就藏在它的 7种日志里

    记住! 记住! 记住! 上边这张图,她是MySQL更新数据的基础流程,其中包括redo log、bin log、undo log三种日志间的大致关系,好了闲话少...

    Java宝典
  • MySQL 8 复制(十)——组复制性能与限制

    组复制的基本保证是,只有在组中的大多数节点接收到事务并且就并发事务的相对顺序达成一致之后,才会提交事务。其对事务的基本处理流程为:

    用户1148526

扫码关注云+社区

领取腾讯云代金券