你好，我是悟空。

本文主要內容如下：

一、背景

為了保證高可用，之前在測試環境部署了一套 MySQL 雙主模式，當一個主庫服務出現異常，可以將流量切到另外一個主庫，兩個主庫之間相互同步數據。

雙主模式

雙主模式的原理圖如下：

但是經常出現數據沖突的問題，于是我們又把??雙主模式??改為了??主從讀寫分離模式??。主庫作為讀寫庫，再加上一個從庫用來做 I/O 密集型的任務（如大量的數據統計操作）。如下圖所示：

另外從庫復制的模式采用??位點??的方式：指定 binlog 文件和 binlog 位置，這樣從庫就知道了復制的起始位置。(下文會講解這種方式）

雖然改為了主從模式，但依舊遇到了些問題：

• 問題 1：從庫 B 復制數據時，出現了主鍵沖突問題，導致同步失敗，從庫停止復制。猜測因主庫配置的 binlog 日志的格式為 mixed，從庫同步時出現不一致的情況。
• 問題 2：從庫 B 停止復制后，導致很多數據未同步到從庫，出現主從大量數據不一致的情況。
• 問題 3：從庫 B 想要恢復復制，必須先解決同步失敗的問題才能恢復。排查難度較大，耗時。
• 問題 4：從庫 B 恢復時，必須知道同步位點，也就是從哪個 binlog 文件和 binlog 位置斷開復制的，且即使找到了位點，也不是精確的。
• 問題 5：從庫 B 因同步異常導致停止復制到恢復復制這段期間，主庫 A 自動清理了幾天前的 binlog 日志，而這些日志從庫 B 還未來得及同步，進而導致再次同步失敗。
• 問題 6：主從存在同步延遲。

這篇我們來探討下問題 4 和問題 6。

其中問題 4 是一個比較頭疼的問題，我們一般是通過查看從庫 B 當前的同步狀態拿到同步位點，然后設置同步位點后。但是重新啟動同步的時候又會出現同步異常，比如從庫 B 可能會出現 Duplicate entry ‘id_of_R’ for key ‘PRIMARY’ 錯誤，提示出現了主鍵沖突，然后停止同步。

為了減少位點同步引入的復雜度，我們切換成了 GTID 模式。

對于問題 6，本篇也僅限于探討如何觀察延遲，對于如何減少延遲不在本篇探討范圍之內。

接下來我們來展開看下位點同步的痛點。

二、位點同步的痛點

2.1 通過位點同步的原理圖

為了更清晰地理解主從采用位點同步的原理，這里有一個原理圖：

1、主庫會生成多個 binlog 日志文件。

2、從庫的I/O 線程請求指定文件和指定位置的 binlog 日志文件（位點）。

3、主庫 dump 線程獲取指定位點的 binlog 日志。

4、主庫按照從庫發送給來的位點信息讀取 binlog，然后推送 binlog 給從庫。

5、從庫將得到的 binlog 寫到本地的 relay log (中繼日志) 文件中。

6、從庫的 SQL 線程讀取和解析 relay log 文件。

7、從庫的 SQL 線程重放 relay log 中的命令。

當我們使用位點同步的方式時，兩種場景下的操作步驟比較復雜。

2.2 痛點

痛點1：首次開啟主從復制的步驟復雜

• 第一次開啟主從同步時，要求從庫和主庫是一致的。
• 找到主庫的 binlog 位點。
• 設置從庫的 binlog 位點。
• 開啟從庫的復制線程。

痛點2：恢復主從復制的步驟復雜

• 找到從庫復制線程停止時的位點。
• 解決復制異常的事務。無法解決時就需要手動跳過指定類型的錯誤，比如通過設置slave_skip_errors=1032,1062。當然這個前提條件是跳過這類錯誤是無損的。（1062 錯誤是插入數據時唯一鍵沖突；1032 錯誤是刪除數據時找不到行）

不論是首次開啟同步時需要找位點和設置位點，還是恢復主從復制時，設置位點和忽略錯誤，這些步驟都顯得過于復雜，而且容易出錯。所以 MySQL 5.6 版本引入了 GTID，徹底解決了這個困難。

三、GTID 方案

3.1 GTID 是什么？

GTID 的全稱是 Global Transaction Identifier，全局事務 ID，當一個事務提交時，就會生成一個 GTID，相當于事務的唯一標識。

GTID 長這樣：

c5d74746-d7ec-11ec-bf8f-0242ac110002:1

結構：

GTID=server_uuid:gno

server_uuid 是一個實例第一次啟動時自動生成的，是一個全局唯一的值；

gno 是一個整數，初始值是 1，每次提交事務的時候分配給這個事務，并加 1。

每個 MySQL 實例都維護了一個 GTID 集合，用來對應“這個實例執行過的所有事務”。

3.2 GTID 的優勢

• 更簡單的實現 failover，不用以前那樣在需要找位點（log_file 和 log_pos）。
• 更簡單的搭建主從復制。
• 比傳統的復制更加安全。
• GTID是連續的沒有空洞的，保證數據的一致性，零丟失。

3.3 如何啟用 GTID

修改主庫和從庫的配置文件：

#GTID:
gtid_mode=on
enforce_gtid_cnotallow=on

從庫配置同步的參數：

CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
master_auto_positinotallow=1 

其中 master_auto_position 標識主從關系使用的 GTID 協議。

相比之前的配置，MASTER_LOG_FILE 和 MASTER_LOG_POS 參數已經不需要了。

3.4 GTID 同步方案

GTID 同步的原理圖。

GTID 方案：主庫計算主庫 GTID 集合和從庫 GTID 的集合的差集，主庫推送差集 binlog 給從庫。

當從庫設置完同步參數后，主庫 A 的GTID 集合記為集合 x，從庫 B 的 GTID 集合記為 y。從庫同步的邏輯如下：

• 從庫 B 指定主庫 A，基于主備協議簡歷連接。
• 從庫 B 把集合 y 發給主庫 A。
• 主庫 A 計算出集合 x 和集合 y 的差集，也就是集合 x 中存在，集合 y 中不存在的 GTID 集合。比如集合 x 是 1~100，集合 y 是 1~90，那么這個差集就是 91~100。這里會判斷集合 x 是不是包含有集合 y 的所有 GTID，如果不是則說明主庫 A 刪除了從庫 B 需要的 binlog，主庫 A 直接返回錯誤。
• 主庫 A 從自己的 binlog 文件里面，找到第一個不在集合 y 中的事務 GTID，也就是找到了 91。
• 主庫 A 從 GTID = 91 的事務開始，往后讀 binlog 文件，按順序取 binlog，然后發給 B。
• 從庫 B 的 I/O 線程讀取 binlog 文件生成 relay log，SQL 線程解析 relay log，然后執行 SQL 語句。

GTID 同步方案和位點同步的方案區別是：

• 位點同步方案是通過人工在從庫上指定哪個位點，主庫就發哪個位點，不做日志的完整性判斷。
• 而 GTID 方案是通過主庫來自動計算位點的，不需要人工去設置位點，對運維人員友好。

四、如何判斷主從庫是否有延遲

上面提到的問題 6 是主從讀寫分離后，從庫復制存在延遲，接下來我們來探討下如何觀察主從延遲多少的問題。

方案一：判斷從庫的同步狀態參數 seconds_behind_master 是否為 0。（不準確）

方案二：對比位點確保主備無延遲。

方案三：對比 GTID 集合確保主備無延遲。

方案一：查看 seconds_behind_master

可以在從庫上執行 slow slave status 命令來看執行結果里面的 ??seconds_behind_master?? 參數的值，如下圖所示，Seconds_Behind_Master 等于 0

Seconds_Behind_Master 的單位是秒，所以精度不準確。

所以為了保證查詢的數據是和主庫一致的，就需要先判斷 seconds_behind_master 是否已經等于 0，如果不等于 0，就必須等到這個參數變為 0 才能執行查詢請求。

方案二：對比位點

可以通過查看從庫當前的同步位點來確認從庫同步是否有延遲。下圖是在從庫上執行 ??show slave status \G??命令后的結果：

Master_Log_File? 和 Read_Master_Log_Pos 這兩個參數合起來表示的是讀到的主庫的最新位點，第一參數是代表讀取到了哪個文件，第二個是讀取到的文件的位置。

Relay_Master_Log_File? 和 Exec_Master_Log_Pos，這兩個參數合起來表示的是從庫執行的最新位點。

如果紅色框起來的兩個參數：Master_Log_File? 和 Relay_Master_Log_File 相等，則說明從庫讀到的最新文件和主庫上生成的文件相同，這里都是 mysql-bin.000934。

如果藍色框起來的兩個參數 Read_Master_Log_Pos? 和 Exec_Master_Log_Pos 相等，則說明從庫讀到的日志文件的位置和從庫上執行日志文件的位置相同，這里都是 59521082。

當上面兩組參數都相等時，則說明沒有延遲。

方案三：對比 GTID 集合

方案三是對比 GTID 集合。首先我們在從庫上執行  show slave status \G來查看 GTID 集合。

如下圖所示：

Master_UUID 表示當前連接的主庫的 ID。

Auto_Position: 1 表示主備使用了 GTID 協議。

Retrieved_Gtid_Set 表示從庫收到的所有日志的 GTID 集合。

Executed_Gtid_Set 表示從庫已經執行完成的 GTID 集合。

如果 Executed_Gtid_Set 集合是包含 Retrieved_Gtid_Set，則表示從庫接收到的日志已經同步完成。

比如上圖中 Retrieved_Gtid_Set 值為

c5d74746-d7ec-11ec-bf8f-0242ac110002:1-87323

前面一段是主庫 id，后面一段 1-87383 是 GTID 范圍。而Executed_Gtid_Set 的值有兩個集合

7083ae1f-d7ef-11ec-a329-0242ac110002:1-2,
c5d74746-d7ec-11ec-bf8f-0242ac110002:1-87323

Executed_Gtid_Set 的第二個集合和第一個集合完全一致，第一個集合 id 和 集合范圍是上次同步另外一個主庫的記錄。這里說明從庫已經和當前主庫同步完成了。

方案二對比位點和方案三的 GTID 比對都要比方案一的seconds_behind_master 更準確。但是還是沒有達到精確的程度，需要配合半同步復制（semi-sync replication）才能達到。

小結：本篇通過 GTID 的方式更好地實現了主從節點的同步，以及如何觀察主從同步的延遲。

參考資料：

www.passjava.cn

https://time.geekbang.org/column/article/77636

高性能 MySQL 第四版

千金良方：MySQL性能優化金字塔法則

關于我

8 年互聯網開發經驗，擅長微服務、分布式、架構設計。目前在一家大型上市公司從事基礎架構和性能優化工作。

InfoQ 簽約作者、藍橋簽約作者、阿里云專家博主、51CTO 紅人。