容災熱身
容災有幾種方式？
從冷熱來說，分為冷備和熱備。從距離來說，分為同城和異地。
一般而言，大的維度劃分就是兩者的正交：同城冷備，異地冷備，同城熱備，異地熱備。
MySQL如果掛了怎么辦呢？
MySQL可以主從模式部署，如果主掛了，可以將從升級為主。當然，為了節約資源，如果業務允許，在平時運行正常的時候，也可以將部分讀請求分流到從節點。
那主從模式按部署方式又分為哪幾種？
常見的主從模式有幾種，具體的模式也得看實際的業務需要。根據實際的情況，選擇合適的一種架構模式。
1.一主一從模式：一個大佬帶一個小弟，大佬掛了小弟上位。
2.一主多從模式：一個大佬帶一群小弟，只要不全掛，就還能翻盤。
3.級聯主從模式：一個大佬培養了一個親信骨干，其它小弟都由親信骨干培養。
嗯，比喻得不錯，那主節點和從節點怎么保證一致呢？
兩種方式，一種是雙寫兩個db，還有就是主從復制。前者需要耗費大量成本去保證雙寫的最終一致性。所以更常見的是主從復制。
那主從復制，Master做了哪些工作？
當主節點上進行寫操作時，會按照時間先后順序寫入到binlog中。主從復制就是基于binlog進行的，具體流程有兩部分。
首先，當從節點連接到主節點時，主節點會創建一個叫做dump的線程，有多少個從節點，就會創建多少個dump線程；
然后，當主節點的binlog發生變化的時候，dump線程就會通知從節點，并將相應的binlog內容發送給從節點。
主從復制，Slave又做了哪些工作呢？
當開啟主從同步的時候，從節點會創建兩個線程用來完成數據同步工作：
I/O線程連接到主節點，主節點上的dump線程會將binlog的內容發送給I/O線程。它接收到內容后，再將其寫入到本地的relay log。
SQL線程讀取I/O線程寫入的relay log，并且根據relay log的內容對從數據庫做對應的操作。
數據復制
主從復制有幾種模式？
主要有三種模式：異步模式、半同步模式、全同步模式。
異步模式：這種模式下，主節點不關心dump線程同步情況，直接返回成功給客戶。
半同步模式下，主節點只需要接收到其中一臺從節點的返回信息，就會給用戶返回成功，否則需要等待直到超時回滾。
這樣做性能比異步模式會差一些，但可靠性會高一些，保證了binlog至少傳輸到了一個從節點上，不過沒有保證從節點立刻將此事務更新到存儲中。
全同步模式是指主節點和從節點全部執行并提交了，才會向客戶端返回成功。
注意，是提交，而不只是從節點寫入到relay log，這樣主從是強一致性的，但性能損耗非常大，必須在網絡良好的情況下使用。
那全同步模式下，性能會不會很差，有優化空間嗎？
全同步主要性能損耗在于同步等待返回，業界有一個方案叫MAR，即異步多線程強同步復制，只有當備機數據完全同步后，才由主機給予應用事務應答，保障數據不丟失，同時還用多線程思路保證了性能。
MAR可以說是半同步和全同步的折中，經常被稱為強同步。騰訊的明星產品TDSQL，就是使用的MAR做同步。
詳細說一下強同步細節吧。
Master上事務寫到binlog就算結束，將會話保存到session中。接著執行下一輪循環去處理其它請求，這樣就避免讓線程阻塞等待應答了。
然后負責主備同步的dump線程會將binlog立即發送給slave，slave的IO線程收到binlog并寫入到relay log之后，再給主機一個應答。
在Master，會有一組線程來處理應答，收到應答之后找到對應的會話，還可以批量執行commit，并且給客戶端應答。
MySQL一般會使用哪種模式的復制呢？
根據業務需求，如果要求實時性高的話，可以搞同城容災，同城可以選擇全同步模式。
如果要求進一步降低風險的話，異地容災也得搞起來，異地通常會采取異步模式。
業界容災方案
同城容災和異地容災的區別是什么？
同城容災是在相近區域建立兩個數據中心 : 一個負責日常生產運行 ; 一個負責在災難發生后的重建。同城之間的同步速度比較快，可以支持全同步模式。
異地容災主備中心之間的距離較遠， 因此一般采用異步同步，災難情況下會有少量的數據丟失。異地災難備份可以有效防范地震、水災等各類風險。
由于同城災難備份和異地災難備份各有所長，為達到最理想的防災效果，數據中心應考慮采用同城和異地各建立一個災難備份中心。
你有了解過兩地三中心嗎？
兩地三中心即同城雙中心?一個異地中心。同城雙中心由于距離近，數據可以完全同步。異地災備中心因為距離遠，會有一定程度的數據延遲。
同城雙中心具有投資成本低、建設速度快、運維管理相對簡單、可靠性更高等優點。
異地災備中心則具有抗風險能力強的作用，當同城中心因為自然災害等原因而發生故障時，異地災備中心可以用備份數據進行業務恢復。
那災難發生時MySQL該怎么切換呢？
如果是同城強同步的節點，直接切換主從即可。如果是跨城市，這種主要是災難之后的止損，災難地的數據不一定能恢復。
平時事故時間較短，不一定要切到異地冷備。如果時間預期比較長，比如光纖斷了要等幾小時以上的，就需要考慮切到異地冷備，此時會丟失一部分數據，等到恢復之后，再做數據遷移。
MySQL異地雙活怎么做？
前面說的異地冷備其實也是異地雙活的一種。異地雙活是說兩個不同城地域，同時進行服務，并且互相容災。
既然能相互容災，那么兩地數據都需要是完整的，至少是最終完整，所以有個同步的過程。
那你能說說異地雙活的適用場景嗎？
異地雙活非常困難，主要涉及到跨城的網絡存在較大延遲。要做異地雙活，需要對業務場景進行考慮。
如果要完全數據同步，那么兩端需要相互同步數據，一般需要數據沖突較少，并且要接受一定的查詢延時。
還有一種場景，如果增量數據不受存量影響，比如任務表，那么也可以不雙向同步數據，如果一地掛了，可以將用戶的新任務調度到異地，等恢復之后，再遷移回來，缺點就是損失一些記錄。
MySQL是后臺開發中非常重要的領域，容災更是面試環節的高頻考點。
一方面是日常故障怎么做到快速恢復，另一方面，如果真的發生了大型事故 （比如2015年8月，天津爆炸導致騰訊機房受損），怎么把影響降低到最小，這些都是我們需要考慮的問題，若是連冷備兜底都沒有，那么這個項目基本可以說拜拜了。
當然，在面試中，要是問到容災，你能對答如流，甚至拔高，絕對是一個加分項！
● ?校招進騰訊，二本也可以？
●【騰訊面試題】兔子試毒
●【面試官來襲】第一彈之Redis連擊
●【面試官來襲】第二彈之MySQL基礎篇
●【面試官來襲】第三彈之MySQL原理篇
