MySQL 關于slave端Retrieved_Gtid_Set的讀取改進初探

本文為以後學習SLAVE做一個記錄不保證正确性。因為算法沒看懂。

今天朋友問我這樣一個問題@K.I.S.S，在官方文檔中有這樣一段描述：

問為什麼要減去last_received_GTID。

對于這個問題我先檢視了一下這個bug到底修複了什麼問題如下：

大概就是說對于某些I/O線程并沒有完整傳輸的Gtid事物記錄到了RETRIEVED_GTID_SET中這會導緻比較嚴重問題，因為某些監控工具根據這個來判斷是否切換之類的，是以我們加入了一個事物邊界分析器來判斷事物是否完整傳輸，如果完整傳輸才記錄到RETRIEVED_GTID_SET中這是5.7.5過後加入的。總的說來為了進行兩個問題的修複：

1、最後一個gtid 事物是否完整。

2、跨越多個relay log的binlog 得到正确的gtid集合。

其實修改得非常多，不一一列舉，有興趣可以自己看看commit 9dab9dad975d09b8f37f33bf3c522d36fdf1d0f9，這裡列舉幾個我看了的地方。

其實這一塊也說明了解決的什麼問題，我們發現一個事物的binlog event 在relay log中是可以跨檔案的。而在bin log中是不能跨檔案的。僅僅判斷最後一個gtid priv event 是不正确的。是以需要這樣修改。

這個類是完全新加入的，這裡是其中的一些狀态：

這個函數是完全新加入的就是為了完成所說的功能，在read_gtids_and_update_trx_parser_from_relaylog中我看到對檔案所有event進行了讀取，并且用switch進行了不同event類型的處理，但是具體沒有細看。但是最後看到對于對于是否加入retrieve gtid的判斷如下：

實際上就在現在看來應該就是讀取 relay_log的最後一個gtid事物(gtid event或者gtid priv event)同時需要判斷此gtid事物是否完整。對于官方文檔給出的UNION(@@global.gtid_executed, Retrieved_gtid_set - last_received_GTID)，個人覺得這裡的 last_received_GTID應該是經過判斷的，如果完整則不減，如果不完整則減去。

作者微信：