很多公司都採用的mysql主從架構，相信很多人困擾於主從延時問題，這篇文章就系統的講述下mysql主從延時問題。
從canal官網抄個圖
主從同步.png
大致流程如下：
mysql-主從流程.jpg
可以看出從master接到乙個寫請求到資料回放到從庫的時間為t1+t2+t3，
主從延時的時間為t2+t3。一般來說這部分時間為200ms左右，這部分延時是無法避免的。這就導致一些寫入立即讀的場景可能得不到剛才變化的結果。比如，商家發布商品成功後，如果立即跳到已發布商品頁，可能會查不到剛剛發布的商品。
這時商家可能會有很多問號。
這種問題解決方案有三種：
產品互動做調整，在寫請求後讀操作前，加入一些拖時間的互動，以保證資料已經同步到從庫。比如，商家發布商品後，彈出乙個彈框（繼續發布商品 or 去已發布商品頁）。
強制讀主庫。這種方案看起來很low，但是我相信大部分公司都採用的這種方案，原因也很直白：簡單呀！採用了這種方案也就意味著拋棄了從庫的讀擴充套件性。
選擇性讀主庫。
mysql選擇性讀主.jpg
棒！接下來，我們來分析主從同步延時時長遠超預期的原因。我們知道主從延時時間t=t2+t3。網路延遲會導致t2過長，這種情況比較少，而且不是我們討論的重點，就一筆帶過了。實際上我們遇到的大多數情況是t3過長。t3耗時主要在relay log回放資料這一步。可能原因如下：
1. 從庫機器配置比主庫低
從庫的壓力其實比主庫更大。因為從庫除了執行主庫執行的全部寫操作外，還要處理讀請求。
從庫讀壓力過大
如果機器配置一樣，主從延時還是過長，那麼有可能是從庫讀壓力過大，占用過多伺服器資源。可以增加從庫分擔壓力。
大事務這個也很好理解，乙個事務在主庫需要執行五分鐘的話，在從庫回放時也需要五分鐘。延時也就會增加五分鐘。
存在長時間持有exclusive metadata lock的操作
最典型的就是大表ddl。大表ddl一般耗時較長，執行期間會阻塞讀請求。
關於大表ddl參考我的另一篇文章資料庫擴充套件
mysql 延時排查 排查Mysql主從延時的問題
一 背景 突然發現每天中午以及下午的延時變高，檢視主從的延時經常達到10分鐘以上，整體使用的是mysql proxy實現的讀寫分離機制，所以業務的影響主要是插入資料後久久不能查詢到資料。由於使用mysql業務比較多，一時之間不能快速定位，導致該問題存在的較長時間。二 解決思路 1.到了案發時間，下午...
mysql讀寫分離和解決主從同步延時問題
mysql讀寫分離和解決主從同步延時問題 如何實現mysql讀寫分離 基於主從複製架構，簡單來說，就是搞了乙個主庫，掛多個從庫，然後我們單單只是寫主庫，然後主庫會自動把資料同步到從庫上。mysql主從複製原理是什麼 主庫將變更寫binlog日誌，然後從庫連線到主庫後，從庫有乙個io執行緒，將主庫的b...
mysql並行複製降低主從同步延時的思路與啟示
mysql主從複製，讀寫分離 是網際網路用的非常多的mysql架構，主從複製最令人詬病的地方就是，在資料量較大併發量較大的場景下，主從延時會比較嚴重。為什麼mysql主從延時這麼大？回答 從庫使用 單執行緒 重放 relaylog 優化思路是什麼？回答 使用單執行緒重放relaylog使得同步時間會...