一、現(xiàn)象
凌晨對線上一張表添加索引,表數(shù)據(jù)量太大(1億+數(shù)據(jù),數(shù)據(jù)量50G以上),造成主從延遲幾個小時,各個依賴從庫的系統(tǒng)無法查詢數(shù)據(jù),最終影響業(yè)務。
現(xiàn)在就梳理下主從延遲的原理。
二、原理
根據(jù) MySQL 官方文檔 MySQL Replication Implementation Details 中的描述,MySQL 主從復制依賴于三個線程:master
一個線程(Binlog dump thread
),slave
兩個線程(I/O thread
和SQL thread
)。主從復制流程如下圖:
master 服務器和 slave 服務器連接時,創(chuàng)建Binlog dump thread
以發(fā)送bin log
數(shù)據(jù):
- 一個
Binlog dump thread
對應一個 slave 服務器;
Binlog dump thread
從bin log
獲取數(shù)據(jù)時會加鎖,獲取到數(shù)據(jù)后,立即釋放鎖。
當 slave 服務器收到 START_SLAVE 命令時,會創(chuàng)建I/O thread
和SQL thread
:
I/O thread
以拉的方式,從 master 讀取事件,并存儲到 slave 服務器的relay log
中;
SQL thread
從relay log
中讀取事件并執(zhí)行;
slave
可以按照自己的節(jié)奏讀取和更新數(shù)據(jù),也可以隨意操作復制進程(啟動和停止)。
注: START_SLAVE
命令成功啟動線程后,如果后面I/O thread
或SQL thread
因為某些原因停止,則不會有任何的警告,業(yè)務方無法感知??梢酝ㄟ^查看 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í)行某些語句耗時較長,如持有鎖等;
master
執(zhí)行某些DDL
語句時,執(zhí)行的時間較長,在slave
也執(zhí)行相同的時間;
此處創(chuàng)建了索引,咨詢 DBA,產生的bin log
文件有100多G,數(shù)據(jù)量太大,導致從庫I/O thread
一直讀取DDL
操作產生的bin log
事件,而影響到正常的業(yè)務DML
事件的更新,從而表現(xiàn)為主從同步延遲。
四、解決方案
從主從延遲的原因來看,解決方案可以從以下幾個方向入手:
- 業(yè)務選型,對于無法忍受從庫延遲的架構,可選擇分布式架構等,避開從庫延遲問題
- 執(zhí)行時間,對大表進行線上
DDL
操作盡量選擇凌晨等業(yè)務量較小的時候
- 硬件配置,升級從庫硬件配置,如SSD
- 減少請求,增加緩存層,減少讀請求落庫
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接
您可能感興趣的文章:- MySQL主從復制延遲原因以及解決方案
- MySQL5.6升級5.7時出現(xiàn)主從延遲問題排查過程
- MySQL主從同步延遲的原因及解決辦法
- MYSQL主從不同步延遲原理分析及解決方案
- 減少mysql主從數(shù)據(jù)同步延遲問題的詳解
- 深入mysql主從復制延遲問題的詳解
- MySQL主從延遲問題解決