MySQL主從延遲問題應(yīng)該如何解決

本文主要給大家介紹MySQL主從延遲問題應(yīng)該如何解決，文章內(nèi)容都是筆者用心摘選和編輯的，具有一定的針對(duì)性，對(duì)大家的參考意義還是比較大的，下面跟筆者一起了解下MySQL主從延遲問題應(yīng)該如何解決吧。       

面對(duì)拋出這樣的問題，我們先來了解下生產(chǎn)中有哪些主從架構(gòu)？線上生產(chǎn)環(huán)境一般有一主一從，一主多從，多主一叢（級(jí)聯(lián)復(fù)制，MySQL5.7之后才有） ，主主復(fù)制。主從架構(gòu)存在目的就是為了故障切換和讀寫分離。它的原理如下圖：

主云服務(wù)器有一個(gè)工作線程 io dump thread

從云服務(wù)器有兩個(gè)工作線程，一個(gè)是io thread，一個(gè)sql thread。

主庫把外界接收的SQL請(qǐng)求，記錄到自己的binlog日志里面，從庫的

io thread去請(qǐng)求主庫 的binlog日志，并將得到的binlog日志寫到自己的relay log（中繼日志） 文件中；主庫通過io dump thread，給從庫 io thread 傳binlog 日志。

大家可以看到在主庫上事務(wù)的提交是并發(fā)模式的，而從庫只有一個(gè)sql thread 工作，這種不公平的待遇，你說它能不延遲嘛。

剖析其重要的延遲原因在于：

1. 首先就是主庫可以并發(fā)寫入，從庫只能通過單sql thread完成任務(wù)（MySQL5.7之前）

2. MySQL主從之間的同步，本來就不是時(shí)時(shí)同步的，是異步的同步，也就是說，主庫提交事務(wù)之后，從庫才再來執(zhí)行一遍。

3. 在主庫上對(duì)沒有索引大表的列進(jìn)行delete或者update的操作

4. 從庫的硬件配置沒有主庫的好，經(jīng)常忽略從庫的重要性

5. 網(wǎng)絡(luò)問題

解決方法如下：

1. 使用MySQL5.7版本，在5.7中引入了基于組提交的并行復(fù)制,設(shè)置參數(shù)slave_parallel_workers>0  和slave_parallel_type＝'LOGICAL_CLOCK'。

MySQL 5.7才可稱為真正的并行復(fù)制，這其中最為主要的原因就是slave云服務(wù)器的回放與主機(jī)是一致的。就是說主云服務(wù)器上是怎么并行執(zhí)行的，從庫上就怎樣進(jìn)行并行回放。不再有MySQL5.6版本中庫的并行復(fù)制限制。

2. 可以采用percona公司的percona-xtradb-cluster簡(jiǎn)稱PXC架構(gòu)，這種架構(gòu)下可以實(shí)現(xiàn)多節(jié)點(diǎn)寫入，達(dá)到時(shí)時(shí)同步?？蓞⒖祭蠌埖腗ySQL高可用架構(gòu)三部曲之PXC。

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

3. 業(yè)務(wù)初期規(guī)劃的時(shí)候，就要選擇合適的分庫、分表策略，避免單表，或者單庫過大。帶來額外的復(fù)制壓力。從而帶來主從延遲的問題。

4. 避免一些無用的IO消耗，可以上高轉(zhuǎn)速的磁盤，SSD或者PCIE-SSD設(shè)備。

5. 陣列級(jí)別要選擇RAID10，raid cache策略要使用WB堅(jiān)決不要WT。

6. IO調(diào)度要選擇deadline模式。

7. 適當(dāng)調(diào)整buffer pool的大小

8. 避免讓數(shù)據(jù)庫進(jìn)行各種大量運(yùn)算，要記住數(shù)據(jù)庫只是用來存儲(chǔ)數(shù)據(jù)的，讓應(yīng)用端多分擔(dān)些壓力，或者可以通過緩存來完成。

看完以上關(guān)于MySQL主從延遲問題應(yīng)該如何解決，很多讀者朋友肯定多少有一定的了解，如需獲取更多的行業(yè)知識(shí)信息 ，可以持續(xù)關(guān)注我們的行業(yè)資訊欄目的。