Mysql主從同步延遲問題及解決方案

對于主從正常執行，相應的延遲幾乎是不存在的。但是在高QPS下，主從同步卻出現了比較明顯的延遲情況。

_________________________________________________________

問題一：主庫的從庫太多，導緻複制延遲

從庫資料以3-5個為宜，要複制的從節點數量過多，會導緻複制延遲

問題二：從庫硬體比主庫差，導緻複制延遲

檢視Master和Slave的系統配置，可能會因為機器配置不當，包括磁盤I/O、CPU、記憶體等各方面因素造成複制的延遲。一般發生在高并發大資料量寫入場景中

問題三：慢SQL語句過多

假如一條SQL語句執行時間是20秒，那麼從執行完畢到從庫上能查到資料至少需要20秒，這樣就延遲20秒了。

一般要把SQL語句的優化作為正常工作不斷地進行監控和優化，如果單個SQL的寫入時間長，可以修改後分多次寫入。通過檢視慢查詢日志或show full processlist指令，找出執行時間長的查詢語句或大的事務

問題四：主從複制的設計問題

例如主從複制單線程，如果主庫寫并發太大，來不及傳送到從庫，就會導緻延遲。更高版本的Mysql可以支援多線程複制，門戶網站則會開發自己的多線程同步功能。

問題五：主從庫之間的網絡延遲

主從庫的網卡、網線、交換機等網絡裝置都可能成為複制的瓶頸，導緻複制延遲。另外，跨公網的主從複制很容易導緻主從複制延遲

問題六：主庫讀寫壓力大，導緻複制延遲

架構的前端要加buffer及緩存層

門戶網站的解決方案：

優酷的解決方案：資料庫分片技術，而抛棄了由于資料量的越來越多導緻複制延遲的問題。按照user_id進行分片，這樣必須有一個全局的表來管理使用者與shard的關系,根據user_id可以得到share_id，然後根據share_id去指定的分片查詢指定的資料

淘寶的解決方案：修改源碼，對應的機制是Transfer機制，此處通過對Binlog日志重做采用多線程實作，進而提高slave的QPPS

本文出自 “撫琴煮酒” 部落格，請務必保留此出處http://szk5043.blog.51cto.com/8456440/1762981

部落客注：更多參考文章

http://blog.sina.com.cn/s/blog_4ab26d7f0102w0ka.html

http://www.linuxidc.com/Linux/2014-05/101450.htm