MySQL主從同步延遲的原因及解決辦法

由于歷史原因，MySQL復(fù)制基于邏輯的二進(jìn)制日志，而非重做日志。多次被問到何時(shí)MySQL能支持基于物理的復(fù)制，其實(shí)這就看MySQL各位大佬的想法。上次和賴?yán)蠋熌X暴，倏地說道：MySQL會(huì)不會(huì)來個(gè)基于Paxos的redo復(fù)制？

物理復(fù)制的真正好處不在于正確性，因?yàn)榛赗OW格式的日志復(fù)制也已能完全保證復(fù)制的正確性。由于物理日志的寫入是在事務(wù)執(zhí)行過程中就不斷寫入，而二進(jìn)制日志的寫入僅僅在事務(wù)提交時(shí)。因此物理日志的優(yōu)勢(shì)如下所示：

• 復(fù)制架構(gòu)下，大事務(wù)日志提交速度快；
• 復(fù)制架構(gòu)下，主從數(shù)據(jù)延遲小；

假設(shè)執(zhí)行了1個(gè)小時(shí)的某大事務(wù)，在最后提交時(shí)，只需寫入最后提交部分的重做日志（redo log可視為物理日志）。雖然此大事務(wù)重做日志寫入的總量可能有1G，然而在提交時(shí)，數(shù)據(jù)主從復(fù)制僅需將最后一部分日志傳輸?shù)竭h(yuǎn)程從機(jī)，因?yàn)橹暗闹刈鋈罩疽呀?jīng)在執(zhí)行的1個(gè)小時(shí)內(nèi)不斷地同步到從機(jī)。

對(duì)于二進(jìn)制日志，由于其寫入時(shí)間發(fā)生在事務(wù)提交時(shí)，因此假設(shè)產(chǎn)生了1G的二進(jìn)制日志，則需要事務(wù)提交時(shí)間會(huì)包含這1G日志的寫入時(shí)間。在Oracle中有一種說法，事務(wù)的提交速度都是平的，不論事務(wù)的大小。這在MySQL數(shù)據(jù)庫(kù)中是不成立的。即，MySQL的提交速度取決于事務(wù)產(chǎn)生的二進(jìn)制日志的大小，事務(wù)提交的速度不是平的。

更為糟糕的是，MySQL主從復(fù)制在大事務(wù)下的延遲。同樣假設(shè)1個(gè)大事務(wù)在主服務(wù)器上執(zhí)行了1個(gè)小時(shí)，則需要在最后的提交時(shí)間傳送到從服務(wù)器。主從延遲的時(shí)間至少為1個(gè)小時(shí)，若從服務(wù)器執(zhí)行還需1個(gè)小時(shí)，則主從復(fù)制延遲的最壞情況可能是2個(gè)小時(shí)。物理復(fù)制則不存在這樣的限制，原因還是如前所述，事務(wù)提交過程中，日志已經(jīng)在傳輸和回放。

物理復(fù)制雖好，但是也有自己的缺陷，就我自己的實(shí)際體驗(yàn)來看：

• 物理復(fù)制下，主機(jī)壞塊會(huì)導(dǎo)致主從服務(wù)器都無法啟動(dòng)；相信遇到過此問題的同學(xué)不在少數(shù)；
• 此外，做ETL是有困難的，比如怎么將物理日志同步到Hadoop大數(shù)據(jù)平臺(tái)呢？

一言以蔽之，對(duì)于MySQL數(shù)據(jù)庫(kù)來說，任何時(shí)刻不允許有大事務(wù)執(zhí)行。若要執(zhí)行，則將大事務(wù)拆成一個(gè)個(gè)小的子事務(wù)來執(zhí)行。這是最基本心法口訣，但卻又和Oracle有著很大不同?？傊?，氣宗、劍宗，本無好壞，學(xué)會(huì)理解其中的差異，融會(huì)貫通方可達(dá)風(fēng)清揚(yáng)般的致臻境界。

mysql 用主從同步的方法進(jìn)行讀寫分離，減輕主服務(wù)器的壓力的做法現(xiàn)在在業(yè)內(nèi)做的非常普遍。 主從同步基本上能做到實(shí)時(shí)同步。我從別的網(wǎng)站借用了主從同步的原理圖。

在配置好了， 主從同步以后， 主服務(wù)器會(huì)把更新語句寫入binlog,   從服務(wù)器的IO 線程(這里要注意， 5.6.3 之前的IO線程僅有一個(gè)，5.6.3之后的有多線程去讀了，速度自然也就加快了)回去讀取主服務(wù)器的binlog 并且寫到從服務(wù)器的Relay log 里面，然后從服務(wù)器的 的SQL thread 會(huì)一個(gè)一個(gè)執(zhí)行 relay log 里面的sql ， 進(jìn)行數(shù)據(jù)恢復(fù)。

relay 就是 傳遞, relay race 就是接力賽的意思

1. 主從同步的延遲的原因

我們知道， 一個(gè)服務(wù)器開放Ｎ個(gè)鏈接給客戶端來連接的，　這樣有會(huì)有大并發(fā)的更新操作, 但是從服務(wù)器的里面讀取binlog 的線程僅有一個(gè)， 當(dāng)某個(gè)SQL在從服務(wù)器上執(zhí)行的時(shí)間稍長(zhǎng) 或者由于某個(gè)SQL要進(jìn)行鎖表就會(huì)導(dǎo)致，主服務(wù)器的SQL大量積壓，未被同步到從服務(wù)器里。這就導(dǎo)致了主從不一致， 也就是主從延遲。

2. 主從同步延遲的解決辦法

實(shí)際上主從同步延遲根本沒有什么一招制敵的辦法， 因?yàn)樗械腟QL必須都要在從服務(wù)器里面執(zhí)行一遍，但是主服務(wù)器如果不斷的有更新操作源源不斷的寫入， 那么一旦有延遲產(chǎn)生， 那么延遲加重的可能性就會(huì)原來越大。 當(dāng)然我們可以做一些緩解的措施。

• a. 我們知道因?yàn)橹鞣?wù)器要負(fù)責(zé)更新操作， 他對(duì)安全性的要求比從服務(wù)器高， 所有有些設(shè)置可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設(shè)置，而slave則不需要這么高的數(shù)據(jù)安全，完全可以講sync_binlog設(shè)置為0或者關(guān)閉binlog，innodb_flushlog， innodb_flush_log_at_trx_commit 也 可以設(shè)置為0來提高sql的執(zhí)行效率 這個(gè)能很大程度上提高效率。另外就是使用比主庫(kù)更好的硬件設(shè)備作為slave。
• b. 就是把，一臺(tái)從服務(wù)器當(dāng)度作為備份使用， 而不提供查詢， 那邊他的負(fù)載下來了， 執(zhí)行relay log 里面的SQL效率自然就高了。
• c. 增加從服務(wù)器嘍，這個(gè)目的還是分散讀的壓力， 從而降低服務(wù)器負(fù)載。

3. 判斷主從延遲的方法

MySQL提供了從服務(wù)器狀態(tài)命令，可以通過 show slave status 進(jìn)行查看，  比如可以看看Seconds_Behind_Master參數(shù)的值來判斷，是否有發(fā)生主從延時(shí)。

其值有這么幾種：

NULL - 表示io_thread或是sql_thread有任何一個(gè)發(fā)生故障，也就是該線程的Running狀態(tài)是No,而非Yes.
0 - 該值為零，是我們極為渴望看到的情況，表示主從復(fù)制狀態(tài)正常

其它的方法我也沒試過， 暫時(shí)不做評(píng)論

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接