一、現象

凌晨對線上一張表新增索引，表資料量太大(1億+資料，資料量50G以上)，造成主從延遲幾個小時，各個依賴從庫的系統無法查詢資料，最終影響業務。

現在就梳理下主從延遲的原理。

二、原理

根據 MySQL 官方文件 MySQL Replication Implementation Details 中的描述，MySQL 主從複製依賴於三個執行緒：master一個執行緒(Binlog dump thread)，slave兩個執行緒(I/O thread和SQL thread)。主從複製流程如下圖：

master 伺服器和 slave 伺服器連線時，建立Binlog dump thread以傳送bin log

• 一個Binlog dump thread對應一個 slave 伺服器；
• Binlog dump thread從bin log獲取資料時會加鎖，獲取到資料後，立即釋放鎖。

當 slave 伺服器收到 START_SLAVE 命令時，會建立I/O thread和SQL thread：

• I/O thread以拉的方式，從 master 讀取事件，並存儲到 slave 伺服器的relay log中；
• SQL thread從relay log中讀取事件並執行；
• slave可以按照自己的節奏讀取和更新資料，也可以隨意操作複製程序(啟動和停止)。

注: START_SLAVE

通過 SHOW PROCESSLIST 可檢視執行緒狀態:

Binlog dump thread:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
  Id: 2
 User: root
 Host: localhost:32931
  db: NULL
Command: Binlog Dump
 Time: 94
 State: Has sent all binlog to slave; waiting for binlog to
   be updated
 Info: NULL

I/O thread 和 SQL thread:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
  Id: 10
 User: system user
 Host:
  db: NULL
Command: Connect
 Time: 11
 State: Waiting for master to send event
 Info: NULL
 *************************** 2. row ***************************
  Id: 11
 User: system user
 Host:
  db: NULL
Command: Connect
 Time: 11
 State: Has read all relay log; waiting for the slave I/O
   thread to update it
 Info: NULL

三、分析

根據上面的原理，由於slave是單執行緒(I/O thread)讀取資料，單執行緒(SQL thread)更新資料，而master是多執行緒寫入，那麼只要master寫入的頻率大於slave讀取更新的頻率，就有可能出現主從延遲的情況，如:

1. master寫入tps較高，大於slave更新速度；
2. slave執行某些語句耗時較長，如持有鎖等；
3. master執行某些DDL語句時，執行的時間較長，在slave也執行相同的時間；

此處建立了索引，諮詢 DBA，產生的bin log檔案有100多G，資料量太大，導致從庫I/O thread一直讀取DDL操作產生的bin log事件，而影響到正常的業務DML事件的更新，從而表現為主從同步延遲。

四、解決方案

從主從延遲的原因來看，解決方案可以從以下幾個方向入手：

1. 業務選型，對於無法忍受從庫延遲的架構，可選擇分散式架構等，避開從庫延遲問題
2. 執行時間，對大表進行線上DDL操作儘量選擇凌晨等業務量較小的時候
3. 硬體配置，升級從庫硬體配置，如SSD
4. 減少請求，增加快取層，減少讀請求落庫

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對我們的支援。如果你想了解更多相關內容請檢視下面相關連結