MySQL Binlog日誌與主從複製是什麼

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是指全域事務標誌，用來標記主從同步的情況。

當主節點提交一個交易時，會產生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協定實現，每個實例都有獨立的完整資料副本，叢集會自動檢查節點信息，做資料的同步。同時提供單主模式和多主模式，單主模式在主庫宕機後能夠自動選主，所有寫入都在主節點進行，多主模式支援多節點寫入。叢集提供了容錯功能，只要大多數節點正常運行，叢集就能正常提供服務。

2.5 並行回放

事務回放是從函式庫的SQL執行緒執行Relay Log的過程，並行回放是為了提高這個過程的效率，將可以並行進行的交易同時進行。

• 基於邏輯時鐘的平行回放

#因為MySQL本身事務具有ACID的特點，所以從主庫同步到從庫的事務，只要其執行的邏輯時間上有重疊，那麼這兩個事務就能安全的進行並行回放。

• 基於writeSet的平行回放

#將一定時間內關於特定資料區塊區域的交易集合儲存在一個HashMap中。在同一組內的事務或具有重疊邏輯時鐘的事務之間不會發生衝突，而其他情況則無法確定是否存在衝突。

以上是MySQL Binlog日誌與主從複製是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！