binlog複製的災備設計

［導讀］本文主要介紹Booking網站在業務發展過程當中碰到MySQL主庫掛載幾十甚至上百個從庫時探索的解決方案：使用Binlog Server。Binlog Server能夠解決五十個以上從庫時主庫網絡帶寬限制問題，並規避傳統的級聯複製方案的缺點；同時介紹了使用Binlog Server還能夠用於優化異地機房複製和拓撲重組後的主庫故障重組。做者探索問題按部就班的方式以及處理思路值得咱們學習。

Booking網站後臺有着很是複雜的MySQL主從架構，一臺主庫帶五十個甚至有時帶上百個從庫並很多見。當從庫到達這個數量級以後，一個必須重點關注的問題是主庫的網絡帶寬不能被打滿。業界有一個現成的可是有缺陷的的解決方案。咱們探索了另一種能更好適應咱們需求的方案：Binlog Server。咱們認爲Binlog Server能夠簡化災難恢復過程，也能使故障後從庫迅速升級爲新主庫變得容易。下面會詳細描述。

一個MySQL主庫帶多個複製的從庫的時候，每次對主庫的修改都會被每一個從庫請求複製，提供大量二進制日誌服務會致使主庫的網絡帶寬飽和。產生大量二進制日誌的修改是很常見的，下面是兩個例子：

• 在使用行模式binlog日誌複製方式的實例中執行大事務刪除操做

• 對一個大表執行在線結構修改操做(online schema change)

在圖1的拓撲圖中，假設咱們在一個MySQL主庫上部署100個從庫，主庫每產生1M字節的修改每秒都會產生100M字節的複製流量。這和千兆網卡的流量上線很接近了，而這在咱們的主從複製結構中很常見。

圖1: 多從庫的MySQL主從架構

這個問題的傳統解決方案是在主庫和它的從庫之間部署中繼主庫。在圖2的拓撲部署中，與不少從庫直接連到主庫不一樣的是咱們有幾個從主庫複製的中繼主庫，同時每一箇中繼主庫有幾個下級從庫。假設有100個從庫和10箇中繼主庫，這種狀況下容許在打滿網卡流量以前產生10倍於圖1架構的二進制日誌。

圖2: 包含中繼主庫的MySQL主從架構

然而，使用中繼主庫是有風險的：

• 中繼主庫上的主從複製延遲將影響它的全部從庫。

• 若是一箇中繼主庫出現異常，全部該中繼主庫的從庫將中止複製並必須從新初始化，[1] (這會帶來很高的維護成本並有可能產生在線故障，譯者注)

針對圖2第二個問題咱們能夠作深刻研究，一個思路是，若是M1出現故障，能夠把它的從庫的主庫配置指向到其餘中繼主庫，可是沒那麼簡單。

• S1從M1複製的二進制日誌依賴於M1

• M1和M2有不一樣的二進制日誌位置(這兩個庫是不一樣的數據庫，在同一時間二進制日誌狀態、位置可能不一樣，譯者注)

• 手工推動S1的二進制日誌位置到M2是很是難並且可能致使數據不一致。

GTID能夠協助咱們指向從庫，可是它不能解決第一個關於延遲的問題。

實際上咱們不須要中繼主庫的數據，咱們只是須要提供Binlog二進制日誌服務。同時，若是M1和M2能夠提供二進制日誌服務而且日誌位置是相同的，咱們能夠很容易地交換各自的從庫。根據這兩點觀察，咱們構思了Binlog Server二進制日誌服務。

Binlog Server替代圖2中的中繼主庫，每一個Binlog Server作以下事情：

• 從主庫下載二進制日誌

• 與主庫使用相同結構(文件名和內容)保存二進制日誌到磁盤

• 提供二進制日誌給從庫就像它們是這些從庫的二級主庫

固然，若是一個Binlog Server異常了，咱們能夠很容易地把它的從庫指向到其餘Binlog Server就能夠。更驚喜的是，因爲這些Binlog Server沒有本地數據的變化，只是給下游提供日誌流，相對有數據的中繼主庫來講，能夠很好的解決延遲的問題。 
咱們與SkySql合做實施了Binlog Server做爲一個模塊的MaxScale的插件框架。你能夠閱讀這篇博客上的介紹SkySql MySQL複製，MaxScale和Binlog Server。

另外一個案例1：避免遠程站點上的深度嵌套複製 
Binlog Server還能用於規避遠程站點上的深度嵌套複製的問題。

假設有兩個不一樣地域機房，每一個機房須要四個數據庫服務器，當網絡帶寬須要特別關注的時候(E、F、G和H在遠程站點)，圖3的拓撲圖是一個典型的部署方式。

圖3: 使用中繼主庫部署的MySQL異地主從架構

可是這個拓撲結構會受到上述討論問題的影響(複製延遲將從E傳遞至F、G和H，同時E異常以後，F、G、H就會失敗)。若是咱們用圖4的架構就好不少，可是這種架構須要更多的網絡帶寬，並且一旦主複製節點發生問題，異地機房從庫須要重建一套新的主從架構。

圖4: 不包含中繼主庫的異地機房MySQL主從部署

在異地機房主從架構中使用Binlog Server，咱們能夠綜合上面兩種方案的優點(低帶寬使用和中繼數據庫不產生延遲)。拓撲圖以下面圖5。

圖5: 包含Binlog Server的異地機房MySQL主從架構

圖5中的MySQL主從架構中，Binlog Server (X)看起來是一個單點，可是若是它異常了, 從新啓動另一個Binlog Server是很容易的。並且也能夠像圖6示例的在異地機房運行兩個Binlog Servers。在這個部署中，若是Y異常了，G和H能夠指向到X，若是X異常了，E和F能夠指向到Y，Y能夠指向到A。

圖6:包含兩個Binlog Server的異地機房MySQL主從架構

運行Binlog Servers其實不須要更多更好的硬件，在圖6中，X、E、Y、G能夠安裝在同一臺硬件服務器上。

最後，這種架構(有1個或2個Binlog Servers)有一個頗有意思的屬性：若是主站點的主庫發生故障，異地機房從庫能夠收斂到徹底一致的狀態(只要X服務器的二進制正常)。這使得重組MySQL主從架構變得很容易：

• 任何一個從能夠成爲新主庫

• 新主庫的二進制日誌位置在發送寫以前會標註出來

• 其餘的節點成爲新主庫的從庫，在以前提到的二進制日誌位置。

另外一個案例2：簡單的高可用實現

Binlog Server能夠用於高可用架構的實現。假如圖7主庫故障了，咱們但願儘快選出新的主庫，咱們能夠部署GTIDS或使用MHA，可是他們都有缺點。

圖7: 6個從庫直連主庫的MySQL主從架構

• 若是咱們像圖8同樣在主庫和從庫之間部署一個Binlog Server。

• 若是X異常，咱們能把全部從庫指向A

• 若是A異常，全部從庫會達到一個一致的狀態，使得將從庫重組成一個複製樹變得很容易(像上面提到的)。

圖8: 包含Binlog Server的MySQL主從架構

若是咱們但願實現高擴展性和高可用性，咱們能夠部署成圖9的主從架構。

圖9:包含多個Binlog Servers的MySQL主從架構

若是一個Binlog Server異常，它的從庫將指向到其餘Binlog Servers。若是I1失敗了：

• 咱們找到有跟多二進制日誌的Binlog Server (咱們假定在這個例子中是I2)

• 咱們將其餘Binlog Servers 指向到I2像圖10同樣。

• 當全部的從庫都達到一個共同的狀態，咱們從新組MySQL主從架構。

圖10: 主庫異常後調整Binlog Server指向的MySQL主從架構

結論：

咱們在咱們的MySQL主從架構中引入了一個新的組件：Binlog Server。它使從庫水平擴展不會超越網絡帶寬的的限制，同時也沒有傳統的級聯複製解決方案的缺點。 
咱們以爲Binlog Server還能夠用於解決其餘兩個問題：遠程站點複製和拓撲重組後的主庫故障重組。後續咱們將帶來的Binlog Server的其餘使用案例，敬請期待更多細節。

[1] 從庫從新初始化的大量工做能夠經過GTIDS或經過採用高可用的中繼主庫（DRBD或Netapp的Snapshot）來避免，可是這兩個解決方案分別會帶來新的問題。