MySQL binlog中的點(diǎn)如此之多,很容易讓人疑惑:有人誤解binlog里的at position 的每個(gè)position代表一個(gè)事務(wù)残拐、有人誤解組提交的一組事務(wù)gtid都相同...下面是個(gè)人整理的binlog中各個(gè)點(diǎn)的用途:
1.at position
用mysqlbinlog解析出來的binlog很容易看到如下內(nèi)容:
# 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字節(jié),因而在默認(rèn)max_binlog_size=1G的配置下,binlog幾乎都是# at 4開頭途茫，以# at 1073744392左右結(jié)尾(1G大小);順帶說明下在備機(jī)show slave status\G;的*Log_Pos代表的也是那個(gè)binlog里的字節(jié):
2.gtid
全局唯一事務(wù)號,沒什么可說的,兩個(gè)不同事務(wù)的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
這個(gè)在每個(gè)binlog產(chǎn)生時(shí)從1開始然后遞增,每增加一個(gè)事務(wù)則sequencenumber就加1,你可能好奇有了gtid何必多此一舉再加個(gè)sequencenumber來標(biāo)識事務(wù)呢,請看下面
4.lastcommitted
這個(gè)在binlog中用來標(biāo)識組提交,同一個(gè)組提交里多個(gè)事務(wù)gtid不同,但lastcommitted確是一致的,MySQL正是依據(jù)各個(gè)事務(wù)的lastcommitted來判斷它們在不在一個(gè)組里;一個(gè)組里的lastcommitted與上一個(gè)組提交事務(wù)的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的事務(wù)在同一個(gè)組里(因?yàn)閘astcommitted都相同,是9)
note: 組提交只與lastcommitted有關(guān),這也是MySQL基于組提交(logic clock)的并行復(fù)制方式即使在gtid關(guān)閉情形下也能生效的原因
5.xid
根據(jù)官方文檔說明，這是用來標(biāo)識xa事務(wù)的
Binlog::XID_EVENT:
Transaction ID for 2PC, written whenever a COMMIT is expected.
