GTID模式解說

2024-09-12 20:30:12

字體：大中小

來源：轉載

供稿：網友

　　從MySQL5.6開始增加了強大的GTID（Global Transaction ID，全局事務ID）這個特性，用來強化數據庫的主備一致性，故障恢復，以及容錯能力。用于取代過去傳統的主從復制（即：基于binlog和position的異步復制）。

　　基于GTID復制的優點：

　　1、根據傳統的復制原理，當連接發生故障時，需要重新連接到master主機，需要找到binlog和position，然后change master to 連接到master主機，此過程需要人工來做，比較麻煩，也容易出錯，尤其是master寫操作較多時，更不容易確定position，如果flush table with read lock，勢必會影響到線上業務。而GTID復制方式不需要找master的binlog和position，只需要知道master的ip、端口、賬號密碼，即可進行復制，MySQl會通過內部機制自動找點同步（MASTER_AUTO_POSITION=1）
　　簡單來說就是：簡化復制。傳統復制是基于file和position來實現的，而file和position是人為確定的，file還好一些，但是position卻是實時變動的，難以確定，除非對全庫加讀鎖，但這勢必會對線上業務產生影響，GTID會自動找position進行數據同步

　　2、多線程復制（基于庫），在MySQL5.6以前的版本，slave的復制是單線程的。一個事件一個事件的讀取應用。而master是并發寫入的，所以延遲是避免不了的。唯一有效的方法是把多個庫放在多臺slave，這樣又有點浪費服務器。在MySQL5.6里面，我們可以把多個表放在多個庫，這樣就可以使用多線程復制，當只有1個庫，多線程復制是沒有用的（即：所謂的并行復制）
　　簡單來說就是：跟多線程復制相關。多線程復制是基于組提交方式實現的，而組提交信息是存儲在GTID中的

　　GTID的作用：

　　1、根據GTID可以知道事務最初是在哪個實例上提交的
　　2、GTID的存在方便了Replication的Failover

　　GTID復制實現的工作原理：
　　1、master更新數據時，會在事務前產生GTID，一同記錄到binlog日志中
　　2、slave端的I/O線程將變更的binlog，寫入到本地的relay log中
　　3、SQL線程從relay log中獲取GTID，然后對比slave端的binlog是否有記錄（所以MySQL5.6 slave端必須開啟binlog）
　　4、如果有記錄，說明該GTID的事務已經執行，slave會忽略
　　5、如果沒有記錄，slave就會從relay log中執行該GTID的事務，并記錄到binlog
　　6、在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描

　　GTID使用限制：
　　1、 MySQL5.7之后才開始支持動態切換GTID相關的參數
　　2、不支持CREATE TABLE ... SELECT statements
　　3、不支持CREATE TEMPORARY TABLE statements inside transactions
　　4、 transaction or statement 既更新了事務表又更新了非事務表
　　5、使用GTID復制從庫跳過錯誤時，不支持執行sql_slave_skip_counter參數的語法

　　以下內容是筆者從博客、論壇等收集的資料，不保證正確性，僅供參考：

　　1、gtid_executed
　　在當前實例上執行過的GTID集合，實際上包含了所有記錄到binlog中的事務。所以，設置set sql_log_bin=0后執行的事務不會生成binlog事件，也不會被記錄到gtid_executed中。執行reset master可以將該變量清空

　　2、gtid_purged
　　binlog不可能永久停留在服務器上，需要進行定期清理（如通過expire_logs_days），否則遲早它會把磁盤空間用完。gtid_purged用于記錄已經被清除了的binlog事務集合，它是gtid_executed的子集。只有gtid_executed為空時才能手動設置該變量，此時會同時更新gtid_executed為和gtid_purged相同的值。gtid_executed為空意味著要么之前沒有啟動過基于GTID的復制，要么執行過reset master。執行reset master時同樣也會把gtid_purged置空，即始終保持gtid_purged是gtid_executed的子集。