從上篇文章我們知道主備同步是依賴于 binlog，主庫負責生産 binlog，備庫負責消費 binlog，進而實作主備同步。
今天我們來學習一下主備同步裡的一個重點的問題：主備延時。
主備延時，簡單來說，就是主庫和備庫的資料一緻出現一定的時間差，比如備庫的此刻的資料快照是主備5分鐘前的資料快照，那就說明主備延時有5分鐘。
主備延遲是怎麼産生的
産生主備延遲的根本原因是備庫上消費 binlog 的速度趕不上主庫産生 binlog 的速度。比如：
大事務，例如一次性delete很多資料；
大表的DDL；
備庫壓力大。例如有些像運維、訂單等統計分析在備機上跑；
主備庫的伺服器的配置不同，主庫的伺服器配置好，備庫的伺服器配置差。
主備延遲的排查之路
網絡
網絡可能導緻主備延遲的問題，比如主庫或者備庫的帶寬滿負載、主備之間網絡延遲很大，有可能會導緻主庫的 binlog 沒有全量傳輸到備庫，造成延遲。
機器性能
備庫 使用了爛機器？ 比如主庫使用了 SSD，而備庫使用的是 SATA。
備庫 高負載？ 可能在備庫上做統計分析，導緻備庫的負載很高。可使用 top 指令進行排查。
備庫 磁盤有問題？ 磁盤、raid卡、排程政策有問題的情況下，有的時候會出現單個IO延遲很高的情況。可使用 iostat 檢視 IO 運作情況。
大事務
是否經常有大事務？ 比如在 RBR 模式下，執行帶有大量的 delete 操作，或者一個表的 alter 操作等，都會導緻延時情況的發生。可通過 processlist 指令檢視相關資訊，或者使用 mysqlbinlog 檢視 binlog 中的 SQL 就能快速确認。
鎖
鎖沖突問題也可能導緻備庫的 SQL 線程執行慢。比如一些 select ... for update 的 SQL。可通過 processlist 和 檢視 information_schema 下面與鎖和事務相關的表來檢視分析。
參數
如果使用的是 InnoDB 引擎，可以調整 innodb_flush_log_at_trx_commit、sync_binlog 參數來提升複制速度。
sync_binlog 的預設值是 0，MySQL 不會将 binlog 同步到磁盤，其值表示每寫多少 binlog 同步一次磁盤。
innodb_flush_log_at_trx_commit 其值表示每一次事務送出或事務外的指令需要把日志 flush 到磁盤。
注：這種調整可能會影響資料的安全性，需要結合業務來考慮。
多線程
在 MySQL 5.6 版本之前，MySQL采用單線程複制，而從 5.6 開始，正式支援多線程複制。
如果是單線程同步，單個線程存在寫入瓶頸，導緻主備延遲，那就先調整為多線程試試效果。
可以通過 show processlist 檢視是否有多個同步線程，也可以檢視參數的方式檢視是否使用多線程(show variables like '%備庫_parallel%')
當你看到是上圖這種結果的時候，恭喜你，你使用的是單線程。使用下面那行指令改造成多線程複制：
STOP 備庫 SQL_THREAD;SET GLOBAL 備庫_parallel_type='LOGICAL_CLOCK';SET GLOBAL 備庫_parallel_workers=8;START 備庫 SQL_THREAD;
改造後如下圖所示：
參考資料