從上篇文章我們知道主備同步是依賴于 binlog，主庫負(fù)責(zé)生產(chǎn) binlog，備庫負(fù)責(zé)消費 binlog，從而實現(xiàn)主備同步。

今天我們來學(xué)習(xí)一下主備同步里的一個重點的問題：主備延時。

主備延時，簡單來說，就是主庫和備庫的數(shù)據(jù)一致出現(xiàn)一定的時間差，比如備庫的此刻的數(shù)據(jù)快照是主備5分鐘前的數(shù)據(jù)快照，那就說明主備延時有5分鐘。

主備延遲是怎么產(chǎn)生的

產(chǎn)生主備延遲的根本原因是備庫上消費 binlog 的速度趕不上主庫產(chǎn)生 binlog 的速度。比如：

大事務(wù)，例如一次性delete很多數(shù)據(jù)；

大表的DDL；

備庫壓力大。例如有些像運維、訂單等統(tǒng)計分析在備機(jī)上跑；

主備庫的服務(wù)器的配置不同，主庫的服務(wù)器配置好，備庫的服務(wù)器配置差。

主備延遲的排查之路

網(wǎng)絡(luò)

網(wǎng)絡(luò)可能導(dǎo)致主備延遲的問題，比如主庫或者備庫的帶寬滿負(fù)載、主備之間網(wǎng)絡(luò)延遲很大，有可能會導(dǎo)致主庫的 binlog 沒有全量傳輸?shù)絺鋷?#xff0c;造成延遲。

機(jī)器性能

備庫 使用了爛機(jī)器？ 比如主庫使用了 SSD，而備庫使用的是 SATA。

備庫 高負(fù)載？ 可能在備庫上做統(tǒng)計分析，導(dǎo)致備庫的負(fù)載很高。可使用 top 命令進(jìn)行排查。

備庫 磁盤有問題？ 磁盤、raid卡、調(diào)度策略有問題的情況下，有的時候會出現(xiàn)單個IO延遲很高的情況。可使用 iostat 查看 IO 運行情況。

大事務(wù)

是否經(jīng)常有大事務(wù)？ 比如在 RBR 模式下，執(zhí)行帶有大量的 delete 操作，或者一個表的 alter 操作等，都會導(dǎo)致延時情況的發(fā)生。可通過 processlist 命令查看相關(guān)信息，或者使用 mysqlbinlog 查看 binlog 中的 SQL 就能快速確認(rèn)。

鎖

鎖沖突問題也可能導(dǎo)致備庫的 SQL 線程執(zhí)行慢。比如一些 select ... for update 的 SQL。可通過 processlist 和 查看 information_schema 下面與鎖和事務(wù)相關(guān)的表來查看分析。

參數(shù)

如果使用的是 InnoDB 引擎，可以調(diào)整 innodb_flush_log_at_trx_commit、sync_binlog 參數(shù)來提升復(fù)制速度。

sync_binlog 的默認(rèn)值是 0，MySQL 不會將 binlog 同步到磁盤，其值表示每寫多少 binlog 同步一次磁盤。

innodb_flush_log_at_trx_commit 其值表示每一次事務(wù)提交或事務(wù)外的指令需要把日志 flush 到磁盤。

注：這種調(diào)整可能會影響數(shù)據(jù)的安全性，需要結(jié)合業(yè)務(wù)來考慮。

多線程

在 MySQL 5.6 版本之前，MySQL采用單線程復(fù)制，而從 5.6 開始，正式支持多線程復(fù)制。

如果是單線程同步，單個線程存在寫入瓶頸，導(dǎo)致主備延遲，那就先調(diào)整為多線程試試效果。

可以通過 show processlist 查看是否有多個同步線程，也可以查看參數(shù)的方式查看是否使用多線程(show variables like '%備庫_parallel%')

當(dāng)你看到是上圖這種結(jié)果的時候，恭喜你，你使用的是單線程。使用下面那行命令改造成多線程復(fù)制：

STOP 備庫 SQL_THREAD;SET GLOBAL 備庫_parallel_type='LOGICAL_CLOCK';SET GLOBAL 備庫_parallel_workers=8;START 備庫 SQL_THREAD;

改造后如下圖所示：

參考資料

總結(jié)

以上是生活随笔為你收集整理的mysql 主备及时_MySQL高可用（二）主备延时如何解决？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。