圖解?MySQL?面試題?——?容災篇

不多說，直接發(fā)車！
今天我們要講的就是MySQL的容災。



容災一直是后臺開發(fā)中的重點，如果是線上服務出了問題，沒有合適的容災機制，那么對業(yè)務來說一定會是個沉重的打擊，但是容災同時也是拉開能力差距的難點，需要有強勁的實力才能把握住。
不知道阿柴能不能經(jīng)受住這樣的考驗。
現(xiàn)在，就讓我們繼續(xù)開啟這場沉浸式面試吧。


容災熱身

容災有幾種方式？

從冷熱來說，分為冷備和熱備。從距離來說，分為同城和異地。

一般而言，大的維度劃分就是兩者的正交：同城冷備，異地冷備，同城熱備，異地熱備。

MySQL如果掛了怎么辦呢？

MySQL可以主從模式部署，如果主掛了，可以將從升級為主。當然，為了節(jié)約資源，如果業(yè)務允許，在平時運行正常的時候，也可以將部分讀請求分流到從節(jié)點。

那主從模式按部署方式又分為哪幾種？

常見的主從模式有幾種，具體的模式也得看實際的業(yè)務需要。根據(jù)實際的情況，選擇合適的一種架構模式。

1.一主一從模式：一個大佬帶一個小弟，大佬掛了小弟上位。

2.一主多從模式：一個大佬帶一群小弟，只要不全掛，就還能翻盤。

3.級聯(lián)主從模式：一個大佬培養(yǎng)了一個親信骨干，其它小弟都由親信骨干培養(yǎng)。

嗯，比喻得不錯，那主節(jié)點和從節(jié)點怎么保證一致呢？

兩種方式，一種是雙寫兩個db，還有就是主從復制。前者需要耗費大量成本去保證雙寫的最終一致性。所以更常見的是主從復制。

那主從復制，Master做了哪些工作？

當主節(jié)點上進行寫操作時，會按照時間先后順序?qū)懭氲絙inlog中。主從復制就是基于binlog進行的，具體流程有兩部分。

首先，當從節(jié)點連接到主節(jié)點時，主節(jié)點會創(chuàng)建一個叫做dump的線程，有多少個從節(jié)點，就會創(chuàng)建多少個dump線程；

然后，當主節(jié)點的binlog發(fā)生變化的時候，dump線程就會通知從節(jié)點，并將相應的binlog內(nèi)容發(fā)送給從節(jié)點。

主從復制，Slave又做了哪些工作呢？

當開啟主從同步的時候，從節(jié)點會創(chuàng)建兩個線程用來完成數(shù)據(jù)同步工作：

I/O線程連接到主節(jié)點，主節(jié)點上的dump線程會將binlog的內(nèi)容發(fā)送給I/O線程。它接收到內(nèi)容后，再將其寫入到本地的relay log。

SQL線程讀取I/O線程寫入的relay log，并且根據(jù)relay log的內(nèi)容對從數(shù)據(jù)庫做對應的操作。

數(shù)據(jù)復制

主從復制有幾種模式？

主要有三種模式：異步模式、半同步模式、全同步模式。

異步模式：這種模式下，主節(jié)點不關心dump線程同步情況，直接返回成功給客戶。

半同步模式下，主節(jié)點只需要接收到其中一臺從節(jié)點的返回信息，就會給用戶返回成功，否則需要等待直到超時回滾。

這樣做性能比異步模式會差一些，但可靠性會高一些，保證了binlog至少傳輸?shù)搅艘粋€從節(jié)點上，不過沒有保證從節(jié)點立刻將此事務更新到存儲中。

全同步模式是指主節(jié)點和從節(jié)點全部執(zhí)行并提交了，才會向客戶端返回成功。

注意，是提交，而不只是從節(jié)點寫入到relay log，這樣主從是強一致性的，但性能損耗非常大，必須在網(wǎng)絡良好的情況下使用。

那全同步模式下，性能會不會很差，有優(yōu)化空間嗎？

全同步主要性能損耗在于同步等待返回，業(yè)界有一個方案叫MAR，即異步多線程強同步復制，只有當備機數(shù)據(jù)完全同步后，才由主機給予應用事務應答，保障數(shù)據(jù)不丟失，同時還用多線程思路保證了性能。

MAR可以說是半同步和全同步的折中，經(jīng)常被稱為強同步。騰訊的明星產(chǎn)品TDSQL，就是使用的MAR做同步。

詳細說一下強同步細節(jié)吧。

Master上事務寫到binlog就算結束，將會話保存到session中。接著執(zhí)行下一輪循環(huán)去處理其它請求，這樣就避免讓線程阻塞等待應答了。

然后負責主備同步的dump線程會將binlog立即發(fā)送給slave，slave的IO線程收到binlog并寫入到relay log之后，再給主機一個應答。

在Master，會有一組線程來處理應答，收到應答之后找到對應的會話，還可以批量執(zhí)行commit，并且給客戶端應答。

綜合來看，MAR強同步復制的特點保證了節(jié)點間數(shù)據(jù)的較強一致性，又將串行同步操作異步化，還引入線程池能力，保證同城情況下TPS幾乎不會下降。
能了解強同步說明對業(yè)界先進實踐是有了解的，妥妥加分。

MySQL一般會使用哪種模式的復制呢？

根據(jù)業(yè)務需求，如果要求實時性高的話，可以搞同城容災，同城可以選擇全同步模式。

如果要求進一步降低風險的話，異地容災也得搞起來，異地通常會采取異步模式。

業(yè)界容災方案

同城容災和異地容災的區(qū)別是什么？

同城容災是在相近區(qū)域建立兩個數(shù)據(jù)中心 : 一個負責日常生產(chǎn)運行 ; 一個負責在災難發(fā)生后的重建。同城之間的同步速度比較快，可以支持全同步模式。

異地容災主備中心之間的距離較遠， 因此一般采用異步同步，災難情況下會有少量的數(shù)據(jù)丟失。異地災難備份可以有效防范地震、水災等各類風險。

由于同城災難備份和異地災難備份各有所長，為達到最理想的防災效果，數(shù)據(jù)中心應考慮采用同城和異地各建立一個災難備份中心。

你有了解過兩地三中心嗎？

兩地三中心即同城雙中心?一個異地中心。同城雙中心由于距離近，數(shù)據(jù)可以完全同步。異地災備中心因為距離遠，會有一定程度的數(shù)據(jù)延遲。

同城雙中心具有投資成本低、建設速度快、運維管理相對簡單、可靠性更高等優(yōu)點。

異地災備中心則具有抗風險能力強的作用，當同城中心因為自然災害等原因而發(fā)生故障時，異地災備中心可以用備份數(shù)據(jù)進行業(yè)務恢復。

那災難發(fā)生時MySQL該怎么切換呢？

如果是同城強同步的節(jié)點，直接切換主從即可。如果是跨城市，這種主要是災難之后的止損，災難地的數(shù)據(jù)不一定能恢復。

平時事故時間較短，不一定要切到異地冷備。如果時間預期比較長，比如光纖斷了要等幾小時以上的，就需要考慮切到異地冷備，此時會丟失一部分數(shù)據(jù)，等到恢復之后，再做數(shù)據(jù)遷移。

MySQL異地雙活怎么做？

前面說的異地冷備其實也是異地雙活的一種。異地雙活是說兩個不同城地域，同時進行服務，并且互相容災。

既然能相互容災，那么兩地數(shù)據(jù)都需要是完整的，至少是最終完整，所以有個同步的過程。

如果出現(xiàn)異常，可以將流量切到另一個地域，快速恢復。

那你能說說異地雙活的適用場景嗎？

異地雙活非常困難，主要涉及到跨城的網(wǎng)絡存在較大延遲。要做異地雙活，需要對業(yè)務場景進行考慮。

如果要完全數(shù)據(jù)同步，那么兩端需要相互同步數(shù)據(jù)，一般需要數(shù)據(jù)沖突較少，并且要接受一定的查詢延時。

還有一種場景，如果增量數(shù)據(jù)不受存量影響，比如任務表，那么也可以不雙向同步數(shù)據(jù)，如果一地掛了，可以將用戶的新任務調(diào)度到異地，等恢復之后，再遷移回來，缺點就是損失一些記錄。

MySQL是后臺開發(fā)中非常重要的領域，容災更是面試環(huán)節(jié)的高頻考點。

一方面是日常故障怎么做到快速恢復，另一方面，如果真的發(fā)生了大型事故 （比如2015年8月，天津爆炸導致騰訊機房受損），怎么把影響降低到最小，這些都是我們需要考慮的問題，若是連冷備兜底都沒有，那么這個項目基本可以說拜拜了。

當然，在面試中，要是問到容災，你能對答如流，甚至拔高，絕對是一個加分項！