一文詳解MySQL Binlog日志與主從復制

Posted on by

1. Binlog日志的介紹

Binlog是Binary log的縮寫，即二進制日志。Binlog主要有三個作用：持久化時將隨機IO轉化為順序IO，主從復制以及數據恢復。本文重點主從復制相關的問題。

Binlog日志由一個索引文件與很多日志文件組成，每個日志文件由魔數以及事件組成，每個日志文件都會以一個Rotate類型的事件結束。

image.png

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

事件頭的結構如下所示：

image.png

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

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

2. 主從復制

2.1 主從復制的流程

image.png

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返回。

image.png

2.4 MGR模式

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

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

2.5 並行回放

事務回放是從庫的SQL線程執行Relay Log的過程，並行回放是為瞭提高這一過程的效率，將可以並行進行的事務同時進行。

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

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

  • 基於writeSet的並行回放

使用一個HashMap保存一定時間內針對某一塊數據區域的事務的集合。如果事務在同一組內或者是邏輯時鐘有重疊，說明沒有沖突，其他情況不能確定是否有沖突。

到此這篇關於一文詳解MySQL Binlog日志與主從復制的文章就介紹到這瞭,更多相關MySQL Binlog日志內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：