最近一段時間内,無論在部落格評論還是私信裡,技術老鐵們都對老張寫的部落格表示認可和支援,我很欣慰!從業多年就希望有一天能把自己學過的東西,遇到的問題,分享出來!我們大家一起進步!
今兒打算給大家分享的是如何解決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. 避免讓資料庫進行各種大量運算,要記住資料庫隻是用來存儲資料的,讓應用端多分擔些壓力,或者可以通過緩存來完成。