一、現(xiàn)象
凌晨對(duì)線上一張表添加索引,表數(shù)據(jù)量太大(1億+數(shù)據(jù),數(shù)據(jù)量50G以上),造成主從延遲幾個(gè)小時(shí),各個(gè)依賴從庫的系統(tǒng)無法查詢數(shù)據(jù),最終影響業(yè)務(wù)。
現(xiàn)在就梳理下主從延遲的原理。
二、原理
根據(jù) MySQL 官方文檔 MySQL Replication Implementation Details 中的描述,MySQL 主從復(fù)制依賴于三個(gè)線程:master
一個(gè)線程(Binlog dump thread
),slave
兩個(gè)線程(I/O thread
和SQL thread
)。主從復(fù)制流程如下圖:
master 服務(wù)器和 slave 服務(wù)器連接時(shí),創(chuàng)建Binlog dump thread
以發(fā)送bin log
數(shù)據(jù):
-
一個(gè)
Binlog dump thread
對(duì)應(yīng)一個(gè) slave 服務(wù)器; -
Binlog dump thread
從bin log
獲取數(shù)據(jù)時(shí)會(huì)加鎖,獲取到數(shù)據(jù)后,立即釋放鎖。
當(dāng) slave 服務(wù)器收到 START_SLAVE 命令時(shí),會(huì)創(chuàng)建I/O thread
和SQL thread
:
-
I/O thread
以拉的方式,從 master 讀取事件,并存儲(chǔ)到 slave 服務(wù)器的relay log
中; -
SQL thread
從relay log
中讀取事件并執(zhí)行; -
slave
可以按照自己的節(jié)奏讀取和更新數(shù)據(jù),也可以隨意操作復(fù)制進(jìn)程(啟動(dòng)和停止)。
注: START_SLAVE
命令成功啟動(dòng)線程后,如果后面I/O thread
或SQL thread
因?yàn)槟承┰蛲V梗瑒t不會(huì)有任何的警告,業(yè)務(wù)方無法感知。可以通過查看 slave 的 error 日志,或者通過 SHOW SLAVE STATUS 查看 slave 上的線程狀態(tài)。
通過 SHOW PROCESSLIST 可查看線程狀態(tài):
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
三、分析
根據(jù)上面的原理,由于slave
是單線程(I/O thread
)讀取數(shù)據(jù),單線程(SQL thread
)更新數(shù)據(jù),而master
是多線程寫入,那么只要master
寫入的頻率大于slave
讀取更新的頻率,就有可能出現(xiàn)主從延遲的情況,如:
-
master
寫入tps
較高,大于slave
更新速度; -
slave
執(zhí)行某些語句耗時(shí)較長(zhǎng),如持有鎖等; -
master
執(zhí)行某些DDL
語句時(shí),執(zhí)行的時(shí)間較長(zhǎng),在slave
也執(zhí)行相同的時(shí)間;
此處創(chuàng)建了索引,咨詢 DBA,產(chǎn)生的bin log
文件有100多G,數(shù)據(jù)量太大,導(dǎo)致從庫I/O thread
一直讀取DDL
操作產(chǎn)生的bin log
事件,而影響到正常的業(yè)務(wù)DML
事件的更新,從而表現(xiàn)為主從同步延遲。
四、解決方案
從主從延遲的原因來看,解決方案可以從以下幾個(gè)方向入手:
- 業(yè)務(wù)選型,對(duì)于無法忍受從庫延遲的架構(gòu),可選擇分布式架構(gòu)等,避開從庫延遲問題
-
執(zhí)行時(shí)間,對(duì)大表進(jìn)行線上
DDL
操作盡量選擇凌晨等業(yè)務(wù)量較小的時(shí)候 - 硬件配置,升級(jí)從庫硬件配置,如SSD
- 減少請(qǐng)求,增加緩存層,減少讀請(qǐng)求落庫
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)服務(wù)器之家的支持。