MySQL主從延遲解決方案

最近一段時間內，不管在博客評論仍是私信裏，技術老鐵們都對老張寫的博客表示承認和支持，我很欣慰！從業多年就但願有一天能把本身學過的東西，遇到的問題，分享出來！咱們你們一塊兒進步！

今兒打算給你們分享的是如何解決MySQL主從延遲的問題，這個也是一些同窗在生產中面臨的比較棘手的問題，  常常給我打電話或者微信，說張老師，如今監控主從之間的延遲特別大。怎麼辦啊？！有什麼辦法能夠避免延遲嘛？！

     

面對拋出這樣的問題，咱們先來了解下生產中有哪些主從架構？線上生產環境通常有一主一從，一主多從，多主一叢（級聯複製，MySQL5.7以後纔有） ，主主複製。主從架構存在目的就是爲了故障切換和讀寫分離。它的原理以下圖：

主服務器有一個工做線程 io dump thread

從服務器有兩個工做線程，一個是io thread，一個sql thread。

主庫把外界接收的SQL請求，記錄到本身的binlog日誌裏面，從庫的

io thread去請求主庫 的binlog日誌，並將獲得的binlog日誌寫到本身的relay log（中繼日誌） 文件中；主庫經過io dump thread，給從庫 io thread 傳binlog 日誌。

你們能夠看到在主庫上事務的提交是併發模式的，而從庫只有一個sql thread 工做，這種不公平的待遇，你說它能不延遲嘛。

剖析其重要的延遲緣由在於：

1. 首先就是主庫能夠併發寫入，從庫只能經過單sql thread完成任務（MySQL5.7以前）

2. MySQL主從之間的同步，原本就不是時時同步的，是異步的同步，也就是說，主庫提交事務以後，從庫纔再來執行一遍。

3. 在主庫上對沒有索引大表的列進行delete或者update的操做

4. 從庫的硬件配置沒有主庫的好，常常忽略從庫的重要性

5. 網絡問題

解決方法以下：

1. 使用MySQL5.7版本，在5.7中引入了基於組提交的並行複製,設置參數slave_parallel_workers>0  和slave_parallel_type＝'LOGICAL_CLOCK'。

MySQL 5.7纔可稱爲真正的並行複製，這其中最爲主要的緣由就是slave服務器的回放與主機是一致的。就是說主服務器上是怎麼並行執行的，從庫上就怎樣進行並行回放。再也不有MySQL5.6版本中庫的並行複製限制。

2. 能夠採用percona公司的percona-xtradb-cluster簡稱PXC架構，這種架構下能夠實現多節點寫入，達到時時同步。可參考老張的MySQL高可用架構三部曲之PXC。

連接地址：http://sumongodb.blog.51cto.com/4979448/1956086

3. 業務初期規劃的時候，就要選擇合適的分庫、分表策略，避免單表，或者單庫過大。帶來額外的複製壓力。從而帶來主從延遲的問題。

4. 避免一些無用的IO消耗，能夠上高轉速的磁盤，SSD或者PCIE-SSD設備。

5. 陣列級別要選擇RAID10，raid cache策略要使用WB堅定不要WT。

6. IO調度要選擇deadline模式。

7. 適當調整buffer pool的大小

8. 避免讓數據庫進行各類大量運算，要記住數據庫只是用來存儲數據的，讓應用端多分擔些壓力，或者能夠經過緩存來完成。

目前能想到就這些，還望你們一塊兒豐富解決辦法。立刻就要從夏季進入秋季了，在這個收穫的季節，但願各位老鐵，天天都能收穫屬於本身的那份技術帶給你的快樂！