mysql查看复制延时_MySQL 8 中复制延时的测量与监控剖析

新增复制时间戳

MySQL8在binlog文件中，对每一个事务(注意是事务，不是事件)都记录了两个时间戳：original_commit_timestamp和immediate_commit_timestamp，通过计算这两个时间戳的差来测量复制延时。这种延时的测量是基于事务(transaction)的，而不再是基于事件(event)。

original_commit_timestamp： 在产生master节点(事务产生的原始节点)，事务成功commit(写入binlog)的毫秒数(基于unix epoch time：1970-01-01T00:00:00Z算起)

immediate_commit_timestamp： 在即时主机，该事务被成功commit的毫秒数(基于unix epoch time：1970-01-01T00:00:00Z算起)

什么是即时主机？在主从拓扑架构中，即时主机可以被理解为应用该binglog的主机，也可简单理解为slave.

同一个事务在同一主从复制架构中，其original_commit_timestamp都是一样的，而immediate_commit_timestamp则因各主机应用(apply)该事务的时间而异。

在主节点(master)上original_commit_timestamp和immediate_commit_timestamp是一致的,同样在slave 的relaylog里面这两个值也是一致的

#180613 9:52:36 server id 1 end_log_pos 263 GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1528854756197790 immediate_commit_time

stamp=1528854756197790 transaction_length=510242

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

# original_commit_timestamp=1528854756197790 (2018-06-13 09:52:36.197790 CST)

# immediate_commit_timestamp=1528854756197790 (2018-06-13 09:52:36.197790 CST)

/*!80001 SET @@session.original_commit_timestamp=1528854756197790*//*!*/;

SET @@SESSION.GTID_NEXT= '76a5d623-64b0-11e8-9060-5254004332fa:17927'/*!*/;

而在slave的binlog里就不同了

#180613 9:48:52 server id 1 end_log_pos 270 GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1528854532813094 immediate_commit_time

stamp=1528854476838381 transaction_length=510244

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

# original_commit_timestamp=1528854532813094 (2018-06-13 09:48:52.813094 CST)</