快捷導(dǎo)航

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

更新時間：2019年03月26日 09:55:32 作者：BrickCarrier

今天小編就為大家分享一篇關(guān)于MySQL主從同步延遲的原因及解決辦法，小編覺得內(nèi)容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a. 我們知道因為主服務(wù)器要負(fù)責(zé)更新操作，他對安全性的要求比從服務(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í)行效率這個能很大程度上提高效率。另外就是使用比主庫更好的硬件設(shè)備作為slave。
b. 就是把，一臺從服務(wù)器當(dāng)度作為備份使用，而不提供查詢，那邊他的負(fù)載下來了，執(zhí)行relay log 里面的SQL效率自然就高了。
c. 增加從服務(wù)器嘍，這個目的還是分散讀的壓力，從而降低服務(wù)器負(fù)載。

3. 判斷主從延遲的方法

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

其值有這么幾種：