一文詳解MySQL Binlog紀錄檔與主從複製

2022-07-31 14:01:50

1. Binlog紀錄檔的介紹

Binlog是Binary log的縮寫，即二進位制紀錄檔。Binlog主要有三個作用：持久化時將隨機IO轉化為順序IO，主從複製以及資料恢復。本文重點主從複製相關的問題。

Binlog紀錄檔由一個索引檔案與很多紀錄檔檔案組成，每個紀錄檔檔案由魔數以及事件組成，每個紀錄檔檔案都會以一個Rotate型別的事件結束。

對於每個事件，都可以分為事件頭與事件體兩部分：

事件頭的結構如下所示：

事件體的結構包括固定大小與可變大小兩部分。

對於Binlog紀錄檔的格式，做簡單的瞭解即可，感興趣的同學可以深入學習。

2. 主從複製

2.1 主從複製的流程

MySQL主從複製的流程大致如下：

主庫同步自己的Binlog紀錄檔給從庫
從庫的IO執行緒將Binlog紀錄檔內容寫入Relay Log
從庫的SQL執行緒取Relay Log並在資料庫中進行回放

2.2 GTID

GTID是指全域性事務標誌，用來標記主從同步的情況。

master提交一個事務時會產生GTID，並且記錄在Binlog紀錄檔中。從庫的IO執行緒在讀取Binlog紀錄檔時，會將其儲存在自己的Relaylog中，並且將這個值設定到gtid_next中，即下一個要讀取的GTID，從庫讀取這個gtid_next時，會對比自己的Binlog紀錄檔中是否有這個GTID：

如果有這個記錄，說明這個GTID的事務已經執行過了，可以忽略掉（冪等）。
如果沒有這個記錄，slave就會執行該GTID事務，並記錄到自己的Binlog紀錄檔中。

2.3 複製模型

非同步複製：master 把Binlog紀錄檔推播給slave，master不需要等到slave是否成功更新資料到Relay log，主庫直接提交事務即可。這種模式犧牲了資料一致性。
同步複製：每次使用者操作時，必須要保證Master和Slave都執行成功才返回給使用者。
半同步複製：不要求Slave執行成功，而是成功接收Master紀錄檔就可以通知Master返回。

2.4 MGR模式

分散式一致性演演算法Paxos。由至少3個或更多個節點共同組成一個資料庫叢集，事務的提交必須經過半數以上節點同意方可提交提供，支援多寫模式。

MGR 是 share-nothing 的複製方案，基於分散式paxos協定實現，每個範例都有獨立的完整資料副本，叢集自動檢查節點資訊，做資料的同步。同時提供單主模式和多主模式，單主模式在主庫宕機後能夠自動選主，所有寫入都在主節點進行，多主模式支援多節點寫入。同時叢集提供冗餘的容錯功能，保證叢集大多數節點正常叢集就可以正常提供服務。