關于MySQL從庫擴展的探索方案分析
大小：0.5 MB 人氣：0 2017-10-12 需要積分：1
標簽：MySQL(25720)
［導讀］本文主要介紹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復制的二進制日志依賴于M1M1和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。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%
