在某些部署環境中，備庫所在的機器效能要比主庫所在的機器效能差。此時如果機器的資源不足的話就會影響備庫同步的效率；
備庫充當了讀庫，一般情況下主要寫的壓力在於主庫，那麼備庫會提供一部分讀的壓力， 而如果備庫的查詢壓力過大的話，備庫的查詢消耗了大量的cpu資源，那麼必不可少的就會影響同步的速度
大事務執行，如果主庫的乙個事務執行了5分鐘，而binlog的寫入必須要等待事務完成之後，才會傳入備庫，那麼此時在開始執行的時候就已經延遲了5 分鐘了
主庫的寫操作是順序寫binlog， 從庫單執行緒去主庫順序讀binlog，從庫取到binlog之後在本地執行。
mysq|的主從複製都是單執行緒的操作，但是由於主庫是順序寫，所以效率很高，而從庫也是順序讀取主庫的日誌，此時的效率也是比較高的，但是當資料拉取回來之後變成了隨機的操作，而不是順序的，所以此時成本會提高。
從庫在同步資料的同時，可能跟其他查詢的執行緒發生鎖搶占的情況，此時也會發生延時。
當主庫的 tps 併發非常高的時候， 產生的 ddl 數量超過了乙個執行緒所能承受的範圍的時候，那麼也可能帶來延遲
在進行binlog日 志傳輸的時候，如果網路頻寬也不是很好，那麼網路延遲也可能造成資料同步延遲這些就是可能會造成備庫延遲的原因
mysql讀寫分離，主從複製，主從延遲
為了提公升資料庫的效能，一般會採用讀寫分離，即寫請求去主庫，讀請求去從庫。支援開啟多個io執行緒，可以提公升效率。開啟mysql的semi sync 半同步複製功能，即資料落庫，寫入binlog，並至少同步給一台從庫的relay日誌，才算寫成功。從庫開啟多個sql執行緒，可以併發讀取relay日誌，...
主從複製延遲導致坑
背景 線上出現了使用者註冊了多條重覆記錄 排查問題 原來 邏輯 先查詢傳過來的openid是否在從庫中存在，不存在就進行主庫插入。出現問題關鍵點 前端第一次請求時候，判斷從庫不存在，然後主庫插入註冊資料。由於出現複製延遲，前端第二請求過來，因為延遲了從庫查詢還是不存在，那就gg了，又重複插了一條。解...
主從複製延遲及原因
1.主庫方面原因 1 binlog寫入不及時 sync binlog 1 2 預設情況下dump t 是序列傳輸binlog 在併發事務量大時或者大事務,由於dump t 是串型工作的,導致傳送日誌較慢 如何解決問題?必須gtid,使用group commit方式.可以支援dump t並行 3 主庫...