前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >mysql二进制日志文件中同一事务的事件时间点会乱序验证

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

原创
作者头像
wangwei-dba
修改2021-06-10 14:21:50
6880
修改2021-06-10 14:21:50
举报
文章被收录于专栏:mysql-dbamysql-dba

验证过程:

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

代码语言:javascript
复制
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

代码语言:javascript
复制
#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时的时间

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

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档