MySQL -- 主從複製的可靠性與可用性

 

1. 主庫A執行完成一個事務， 寫入binlog ，記爲 T1
2. 而後傳給從庫B，從庫B 接收該binlog ，記爲 T2
3. 從庫B執行完成這個事務，記爲 T3
4. 同步延時： T3-T1

• 同一個事務，在 從庫執行完成的時間 和 主庫執行完成的時間 之間的差值
• SHOW SLAVE STATUS 中的 Seconds_Behind_Master

 

Seconds_Behind_Master

1. 計算方法

• 每一個事務的 binlog 裏面都有一個 時間字段 ，用於記錄該 binlog 在 主庫 上的寫入時間
• 從庫取出當前正在執行的事務的時間字段的值，計算它與當前系統時間點差值，獲得 Seconds_Behind_Master
• 即 T3-T1

1. 若是主庫與從庫的時間不一致， Seconds_Behind_Master 會不會有偏差？

• 通常不會
• 在 從庫鏈接到主庫 時，會經過 SELECT UNIX_TIMESTAMP() 獲取 當前主庫的系統時間
• 若是 從庫 發現 當前主庫的系統時間 與本身的不一致，在計算 Seconds_Behind_Master 會 自動扣除 這部分差值
• 但創建鏈接後，主庫或從庫又修改了系統時間，依然會不許確

1. 在 網絡正常 的狀況下， T2-T1 一般會很是小，此時同步延時的主要來源是 T3-T2

• 從庫消費 relaylog 的速度跟不上主庫生成 binlog 的速度

延時來源

1. 從庫所在 機器的性能 要弱於主庫所在的機器

• 更新請求對於IPOS的壓力 ，在 主庫 和 從庫 上是 無差異 的

1. 非對稱部署 ：20個主庫放在4個機器上，但全部從庫放在一個機器上

• 主從之間可能會 隨時切換 ，如今通常都會採用 相同規格的機器 + 對稱部署

1. 從庫壓力大

• 常見場景：管理後臺的查詢語句
• 從庫上的查詢耗費大量的 CPU資源 和 IO資源 ，影響了同步速度，形成了 同步延時
• 解決方案
• 一主多從 ，分擔讀壓力，通常都會採用
• 經過 binlog 輸出到 外部系統 ，例如Hadoop

1. 大事務

• 主庫上必須等待 事務執行完成 後纔會寫入 binlog ，再傳給從庫
• 常見場景1： 一次性刪除太多數據 （如歸檔的歷史數據）
• 解決方案：控制每一個事務刪除的數據量，分屢次刪除
• 常見場景2： 大表DDL
• 解決方案： gh-ost

1. 從庫的 並行複製能力 （後續展開）

切換策略

可靠性優先

切換過程通常由專門的 HA 系統完成，存在 不可用時間 （主庫A和從庫B都處於 只讀 狀態）

 

1. 判斷 從庫B 的 Seconds_Behind_Master 值，當 小於 某個值（例如5）才繼續下一步
2. 把 主庫A 改成 只讀 狀態（ readonly=true ）
3. 等待 從庫B 的 Seconds_Behind_Master 值降爲 0
4. 把 從庫B 改成 可讀寫 狀態（ readonly=false ）
5. 把 業務請求 切換至 從庫B

可用性優先

不等主從同步完成， 直接把業務請求切換至從庫B ，而且讓 從庫B可讀寫 ，這樣幾乎不存在不可用時間，但可能會 數據不一致

表初始化

CREATE TABLE `t` (
 `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
 `c` INT(11) UNSIGNED DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB;
INSERT INTO t (c) VALUES (1),(2),(3);

插入數據

INSERT INTO t (c) VALUES (4);
-- 主庫上的其它表有大量的更新，致使同步延時爲5S，插入c=4後發起了主從切換
INSERT INTO t (c) VALUES (5);

MIXED

 

1. 主庫A執行完 INSERT c=4 ，獲得 (4,4) ，而後開始執行 主從切換
2. 主從之間有5S的同步延遲，從庫B會先執行 INSERT c=5 ，獲得 (4,5) ，而且會把這個 binlog 發給主庫A
3. 從庫B執行主庫A傳過來的 INSERT c=4 ，獲得 (5,4)
4. 主庫A執行從庫B傳過來的 INSERT c=5 ，獲得 (5,5)
5. 此時主庫A和從庫B會有 兩行 不一致的數據

ROW

 

1. 採用 ROW 格式的 binlog 時，會記錄新插入行的 全部字段的值 ，因此最後只會有 一行 數據不一致
2. 主庫A和從庫B的同步線程都會 報錯並中止 ： duplicate key error

小結

1. 使用 ROW 格式的 binlog ，數據不一致的問題 更容易發現 ，採用 MIXED 或 STATEMENT 格式的 binlog ，數據可能悄悄地不一致
2. 主從切換採用 可用性優先 策略，可能會致使 數據不一致 ，大多數狀況下，優先選擇 可靠性優先 策略
3. 在知足 數據可靠性 的前提下，MySQL的 可用性 依賴於 同步延時 的大小（ 同步延時越小 ， 可用性越高 ）

想免費學習Java工程化、分佈式架構、高併發、高性能、深刻淺出、微服務架構、Spring，MyBatis，Netty源碼分析等技術的朋友，能夠加羣：834962734，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們，歡迎進羣一塊兒深刻交流學習。