MySQL binlog中的点如此之多,很容易让人疑惑:有人误解binlog里的at position 的每个position代表一个事务、有人误解组提交的一组事务gtid都相同...下面是个人整理的binlog中各个点的用途:
1.at position
用mysqlbinlog解析出来的binlog很容易看到如下内容:
# at 259
#161028 16:56:20 server id 1591216 end_log_pos 335 CRC32 0x9f5bee2a Query thread_id=35430137 exec_time=0 error_code=0
这里的at 259的259指的是binlog的第259字节,因而在默认max_binlog_size=1G的配置下,binlog几乎都是# at 4开头，以# at 1073744392左右结尾(1G大小);顺带说明下在备机show slave status\G;的*Log_Pos代表的也是那个binlog里的字节:
2.gtid
全局唯一事务号,没什么可说的,两个不同事务的gtid必定不相同,MySQL官方版本binlog中形式这样:
SET @@SESSION.GTID_NEXT= '0c2751a5-6903-11e6-a7d0-ecf4bbcdc155:1509018357'/*!*/;
MariaDB的gtid形式就有些不一样了,binlog中会这样记录:
/*!100001 SET @@session.gtid_domain_id=0*//*!*/;
/*!100001 SET @@session.server_id=82219*//*!*/;
/*!100001 SET @@session.gtid_seq_no=164690165*//*!*/;
3.sequence_number
#161028 17:38:28 server id 1591216 end_log_pos 1073743679 CRC32 0x092e3ee3 GTID last_committed=1155164 sequence_number=1155168
这个在每个binlog产生时从1开始然后递增,每增加一个事务则sequencenumber就加1,你可能好奇有了gtid何必多此一举再加个sequencenumber来标识事务呢,请看下面
4.lastcommitted
这个在binlog中用来标识组提交,同一个组提交里多个事务gtid不同,但lastcommitted确是一致的,MySQL正是依据各个事务的lastcommitted来判断它们在不在一个组里;一个组里的lastcommitted与上一个组提交事务的sequencenumber相同,这样sequencenumber就必须存在了:
......
xxxxxxxxxxxx GTID last_committed=3 sequence_number=8
xxxxxxxxxxxx GTID last_committed=3 sequence_number=9
xxxxxxxxxxxx GTID last_committed=9 sequence_number=10
......
xxxxxxxxxxxx GTID last_committed=9 sequence_number=24
xxxxxxxxxxxx GTID last_committed=24 sequence_number=25
......
这代表sequencenumber=10到sequencenumber=24的事务在同一个组里(因为lastcommitted都相同,是9)
note: 组提交只与lastcommitted有关,这也是MySQL基于组提交(logic clock)的并行复制方式即使在gtid关闭情形下也能生效的原因
5.xid
根据官方文档说明，这是用来标识xa事务的
Binlog::XID_EVENT:
Transaction ID for 2PC, written whenever a COMMIT is expected.
