我們知道主備同步是依賴於 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;
改造後如下圖所示：
作者：大雜草
原文鏈接：https://www.cnblogs.com/liang24/p/14149425.html