导读
binlog中事务以GTID_EVENT开始, 以XID_EVENT结束, 很多信息都藏在gtid_event中, 比如事务大小, 提交时间等. MTS也会查看gtid中的信息, 还涉及到两阶段提交, 但不是本文的重点, 就不讲了.
注:
-
immediate_ 开头的表示是当前数据库执行的相关信息
-
original_ 开头的表示是主库数据库执行的信息
-
5.7同步到8.0的时候, original_ 开头的信息会被置为0
GTID_LOG_EVENT
gtid_event是一个事务开始的标记.(虽然是提交的时候才获取的…). 主要分为gtid(GTID_LOG_EVENT= 33)和匿名gtid(ANONYMOUS_GTID_LOG_EVENT= 34). 格式是一样的. 这里就只看gtid了
| 对象 | 大小(字节) | 描述 |
|---|---|---|
| GTID_FLAGS | 1 | |
| SID | 16 | server_uuid |
| GNO | 8 | gtid no. 就是看到的那个数字 |
| lt_type | 1 | logical timestamp flag |
| last_committed | 8 if lt_type == 2 else 0 | 上一个事务提交的编号, 一样的话, 就表示是一组的(就可以并行回放) |
| sequence_number | 8 if lt_type == 2 else 0 | 当前事务的编号 |
| immediate_commit_timestamp | 8 | 当前提交时间(产生这个binlog的时间) |
| original_commit_timestamp | 0/8 | 主库的提交时间(原始数据的提交时间) |
| transaction_length | 45300 | 事务大小(含gtid&xid) |
| immediate_server_version | 4 | 当前数据库的版本(产生这个Binlog的库的版本信息) |
| original_server_version | 0/4 | 主库的版本信息(原始数据的数据库版本信息) |
没错, gtid_event到这里就完了. 包含的信息还是很多的.
original_ 计算方式
original_commit_timestamp 的计算方式为: immediate_commit_timestamp 第一bit为1时, 就有immediate_commit_timestamp
否则 immediate_commit_timestamp 就是 immediate_commit_timestamp
说白了, 就是从库回放的时候, 把主库的immediate_commit_timestamp写为original_commit_timestamp , 然后把自己的immediate_commit_timestamp 加了个(1
