为何Binlog中同一个事务的event时间点会乱序?

  • 时间:
  • 浏览:0
  • 来源:神彩大发快3_彩神大发快3官方

4、验证所需数据:sysbench压测后要 遗留的测试数据(可自行造数,只时需一张表富含根小数据即可)

1、操作系统版本:CentOS release 6.5 (Final)

(4) at 259 position,事务的第一三个event,也可是我用于记录事务的begin;说说的event,时间点为15:35:21,通过朋友儿事务操作时记录的时间信息,该时间为执行update说说的时间点 15:35:21,并都在执行begin;说说的时间点15:33:02,说明该event是在执行update说说时产生,并都在在执行begin;说说时产生的。

這個 问題,后要后要 ,笔者可是我相当于知道其中的原理,知道它可是我长那我的,但并沒有 做过具体的案例分析。

直到最近,有某客户问起這個 问題的后要 ,才发觉空口无凭讲不太清楚,遂现场给客户演示了一番才松了口气,也顺便把演示过程记录了下来,分类整理成文,下面,请跟随朋友儿共同来一探究竟吧!

一、服务器环境

(2)以下内容为binlog文件头,event 时间点为手工滚动binlog的时间点2018-10-04 15:31:55,这里并未有任何变化。

(1)从库的relay log中的event时间点会不要与主库binlog中记录的相同事务(这里指GTID相同)event时间点不同?

(1)解析binlog

(3)可能主库发生并发事务,沒有 主库的binlog中记录的event时间点又是何如的呢?

(3) at 194 position,事务的第一三个多多 event,也可是我用于记录事务的GTID的event,时间点为15:36:42,通过朋友儿事务操作时记录的时间信息,该时间为执行commit说说的时间点15:36:42。

IT从业多年,历任运维工程师、高级运维工程师、运维经理、数据库工程师,曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写,熟悉MySQL体系底部形态,Innodb存储引擎,喜好专研开源技术,追求完美。

(6)at 398 position,事务的第一三个event,用于记录事务对应的操作表在内存中的映射ID,时间点仍然是执行update说说的时间点(15:35:21),说明该event也是在执行update说说时产生。

首先,登录到数据库中,显式开启一三个多多 事务。

這個 后要 ,binlog中还未记录新事务的binlog日志,在等待几十秒后要 ,再在数据库中执行update说说修改k列值(这里是单行修改,且sbtest1表的id列为主键,很多update说说执行时间在这里是极小的,可不还可以 忽略不计)

原文发布时间为:2018-12-11

本文作者:罗小波

本文来自云栖社区相互相互合作伙伴“ 老叶茶馆”,了解相关信息可不还可以 关注“iMySQL_WX”微信公众号

从上述binlog的解析内容来看,当前最新的binlog中,除了文件头的event之外,并沒有 其他用户数据产生的event数据,且文件头的所有event的时间点都为2018-10-04 15:31:55,這個 时间点也是在数据库中手动执行binlog滚动说说的时间点,也可是我说:binlog文件头的event是在binlog滚动时就可能产生且写入到了最新的binlog中,且哪些地方地方event与用户数据无关。

3、MySQL 关键参数:innodb_flush_log_at_trx_commit=1; sync_binlog=1; binlog_format=row; gtid_mode=on; enforce_gtid_consistency=on

(1)GTID和xid类型的event是在事务执行commit说说时产生的

這個 后要 ,binlog中仍然还未记录新事务的binlog日志(可能事务并沒有 提交,binlog只会在事务提交时才会写入binlog文件中),现在,朋友儿对该显式事务执行commit说说提交事务。

解析一下最新的Binlog文件中的内容及其对应的时间点信息

(3)执行begin;说说时未产生任何event

作者:罗小波·沃趣科技高级数据库技术专家

本案例分析到此始于英文了,留一三个多多 思考题给朋友儿吧(朋友儿可不还可以 依样画葫芦)。可能是主从架构,沒有 :

(7) at 457 position,事务的第一三个event,用于记录事务的全版操作说说和数据记录,也可是我真正在执行update说说做数据修改(时间点仍然是 15:35:21),说明该event也是在执行update说说时产生。

(2)从库可能启用了log_slave_updates=ON参数,从库自身的binlog中记录的一键复制事务的event会不要与主库binlog中记录的相同事务(这里指GTID相同) event时间点不同?

(5)at 338 position,事务的第一三个多多 event,用于记录事务执行的原始SQL说说(时需启用参数:binlog_rows_query_log_events=ON),时间点仍然是执行update说说的时间点(15:35:21),说明该event也是在执行update说说时产生。

现在,朋友儿解析最新的binlog文件,查看此时binlog中是何如记录该事务产生的event数据的(注意:binlog 中每个event的时间点信息是在生成event的后要 产生的),为了方便朋友儿阅读,后续内容将对binlog做分段说明。

综上所述,在上述binlog解析内容中,用户事务的event有GTID(记录事务GTID)、Query(记录事务begin;说说)、Rows_query(在row格式下记录事务原始SQL说说)、Table_map(记录事务操作表在内存中的映射ID)、Update_rows(记录事务真正操作的说说和修改的具体数据记录)、xid(记录事务commit;说说)几种类型,其中:

导 读

三、验证过程

接下来朋友儿模拟用户对数据执行update操作,且为了验证时需,朋友儿使用了显式事务,且在事务执行过程中人为加入了停顿,以便更清晰地看过binlog中的event是何如记录的。

2、MySQL 版本:Oracle MySQL 5.7.20

(2)Query、Rows_query、Table_map、Update_rows 类型的event是在事务执行update 说说时产生的

二、验证准备

登录到数据库中,手动滚动一下binlog文件

(8)at 761 position,事务的第一三个event,用于记录事务的commit说说,时间点为15:36:42,通过朋友儿事务操作时记录的时间信息,该时间为执行commit说说的时间点15:36:42,说明该event是在执行commit说说时产生的。