由于歷史原因，MySQL復(fù)制基于邏輯的二進(jìn)制日志，而非重做日志。多次被問(wèn)到何時(shí)MySQL能支持基于物理的復(fù)制，其實(shí)這就看MySQL各位大佬的想法。上次和賴?yán)蠋熌X暴，倏地說(shuō)道：MySQL會(huì)不會(huì)來(lái)個(gè)基于Paxos的redo復(fù)制？
成都創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括陽(yáng)曲網(wǎng)站建設(shè)、陽(yáng)曲網(wǎng)站制作、陽(yáng)曲網(wǎng)頁(yè)制作以及陽(yáng)曲網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，陽(yáng)曲網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到陽(yáng)曲省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！物理復(fù)制的真正好處不在于正確性，因?yàn)榛赗OW格式的日志復(fù)制也已能完全保證復(fù)制的正確性。由于物理日志的寫入是在事務(wù)執(zhí)行過(guò)程中就不斷寫入，而二進(jìn)制日志的寫入僅僅在事務(wù)提交時(shí)。因此物理日志的優(yōu)勢(shì)如下所示：
假設(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中有一種說(shuō)法，事務(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ù)提交過(guò)程中，日志已經(jīng)在傳輸和回放。
物理復(fù)制雖好，但是也有自己的缺陷，就我自己的實(shí)際體驗(yàn)來(lái)看：
一言以蔽之，對(duì)于MySQL數(shù)據(jù)庫(kù)來(lái)說(shuō)，任何時(shí)刻不允許有大事務(wù)執(zhí)行。若要執(zhí)行，則將大事務(wù)拆成一個(gè)個(gè)小的子事務(wù)來(lái)執(zhí)行。這是最基本心法口訣，但卻又和Oracle有著很大不同?？傊?，氣宗、劍宗，本無(wú)好壞，學(xué)會(huì)理解其中的差異，融會(huì)貫通方可達(dá)風(fēng)清揚(yáng)般的致臻境界。
mysql 用主從同步的方法進(jìn)行讀寫分離，減輕主服務(wù)器的壓力的做法現(xiàn)在在業(yè)內(nèi)做的非常普遍。 主從同步基本上能做到實(shí)時(shí)同步。我從別的網(wǎng)站借用了主從同步的原理圖。
在配置好了， 主從同步以后， 主服務(wù)器會(huì)把更新語(yǔ)句寫入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ù)器開(kāi)放Ｎ個(gè)鏈接給客戶端來(lái)連接的， 這樣有會(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í)際上主從同步延遲根本沒(méi)有什么一招制敵的辦法， 因?yàn)樗械腟QL必須都要在從服務(wù)器里面執(zhí)行一遍，但是主服務(wù)器如果不斷的有更新操作源源不斷的寫入， 那么一旦有延遲產(chǎn)生， 那么延遲加重的可能性就會(huì)原來(lái)越大。 當(dāng)然我們可以做一些緩解的措施。
3. 判斷主從延遲的方法
MySQL提供了從服務(wù)器狀態(tài)命令，可以通過(guò) show slave status 進(jìn)行查看， 比如可以看看Seconds_Behind_Master參數(shù)的值來(lái)判斷，是否有發(fā)生主從延時(shí)。
其值有這么幾種：
NULL - 表示io_thread或是sql_thread有任何一個(gè)發(fā)生故障，也就是該線程的Running狀態(tài)是No,而非Yes.
0 - 該值為零，是我們極為渴望看到的情況，表示主從復(fù)制狀態(tài)正常
其它的方法我也沒(méi)試過(guò)， 暫時(shí)不做評(píng)論
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)創(chuàng)新互聯(lián)成都網(wǎng)站設(shè)計(jì)公司的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
