關(guān)于MySQL從庫擴展的探索方案分析

　［導(dǎo)讀］本文主要介紹Booking網(wǎng)站在業(yè)務(wù)發(fā)展過程中碰到MySQL主庫掛載幾十甚至上百個從庫時探索的解決方案：使用Binlog Server。Binlog Server可以解決五十個以上從庫時主庫網(wǎng)絡(luò)帶寬限制問題，并規(guī)避傳統(tǒng)的級聯(lián)復(fù)制方案的缺點；同時介紹了使用Binlog Server還可以用于優(yōu)化異地機房復(fù)制和拓?fù)渲亟M后的主庫故障重組。作者探索問題循序漸進(jìn)的方式以及處理思路值得我們學(xué)習(xí)。
　　Booking網(wǎng)站后臺有著非常復(fù)雜的MySQL主從架構(gòu)，一臺主庫帶五十個甚至有時帶上百個從庫并不少見。當(dāng)從庫到達(dá)這個數(shù)量級之后，一個必須重點關(guān)注的問題是主庫的網(wǎng)絡(luò)帶寬不能被打滿。業(yè)界有一個現(xiàn)成的但是有缺陷的的解決方案。我們探索了另外一種能更好適應(yīng)我們需求的方案：Binlog Server。我們認(rèn)為Binlog Server可以簡化災(zāi)難恢復(fù)過程，也能使故障后從庫迅速升級為新主庫變得容易。下面會詳細(xì)描述。
　　一個MySQL主庫帶多個復(fù)制的從庫的時候，每次對主庫的修改都會被每個從庫請求復(fù)制，提供大量二進(jìn)制日志服務(wù)會導(dǎo)致主庫的網(wǎng)絡(luò)帶寬飽和。產(chǎn)生大量二進(jìn)制日志的修改是很常見的，下面是兩個例子：
　　在使用行模式binlog日志復(fù)制方式的實例中執(zhí)行大事務(wù)刪除操作對一個大表執(zhí)行在線結(jié)構(gòu)修改操作（online schema change）
　　在圖1的拓?fù)鋱D中，假設(shè)我們在一個MySQL主庫上部署100個從庫，主庫每產(chǎn)生1M字節(jié)的修改每秒都會產(chǎn)生100M字節(jié)的復(fù)制流量。這和千兆網(wǎng)卡的流量上線很接近了，而這在我們的主從復(fù)制結(jié)構(gòu)中很常見。
　　
　　圖1： 多從庫的MySQL主從架構(gòu)
　　這個問題的傳統(tǒng)解決方案是在主庫和它的從庫之間部署中繼主庫。在圖2的拓?fù)洳渴鹬?，與很多從庫直接連到主庫不同的是我們有幾個從主庫復(fù)制的中繼主庫，同時每個中繼主庫有幾個下級從庫。假設(shè)有100個從庫和10個中繼主庫，這種情況下允許在打滿網(wǎng)卡流量之前產(chǎn)生10倍于圖1架構(gòu)的二進(jìn)制日志。
　　
　　圖2： 包含中繼主庫的MySQL主從架構(gòu)
　　然而，使用中繼主庫是有風(fēng)險的：
　　中繼主庫上的主從復(fù)制延遲將影響它的所有從庫。 如果一個中繼主庫出現(xiàn)異常，所有該中繼主庫的從庫將停止復(fù)制并必須重新初始化，［1］ （這會帶來很高的維護成本并有可能產(chǎn)生在線故障，譯者注）
　　針對圖2第二個問題我們可以做深入研究，一個思路是，如果M1出現(xiàn)故障，可以把它的從庫的主庫配置指向到其他中繼主庫，但是沒那么簡單。
　　S1從M1復(fù)制的二進(jìn)制日志依賴于M1M1和M2有不同的二進(jìn)制日志位置（這兩個庫是不同的數(shù)據(jù)庫，在同一時間二進(jìn)制日志狀態(tài)、位置可能不同，譯者注） 手工推進(jìn)S1的二進(jìn)制日志位置到M2是非常難而且可能導(dǎo)致數(shù)據(jù)不一致。
　　GTID可以協(xié)助我們指向從庫，但是它不能解決第一個關(guān)于延遲的問題。
　　實際上我們不需要中繼主庫的數(shù)據(jù)，我們只是需要提供Binlog二進(jìn)制日志服務(wù)。同時，如果M1和M2可以提供二進(jìn)制日志服務(wù)并且日志位置是相同的，我們可以很容易地交換各自的從庫。根據(jù)這兩點觀察，我們構(gòu)思了Binlog Server二進(jìn)制日志服務(wù)。
　　Binlog Server替代圖2中的中繼主庫，每個Binlog Server做如下事情：
　　從主庫下載二進(jìn)制日志與主庫使用相同結(jié)構(gòu)（文件名和內(nèi)容）保存二進(jìn)制日志到磁盤提供二進(jìn)制日志給從庫就像它們是這些從庫的二級主庫
　　當(dāng)然，如果一個Binlog Server異常了，我們可以很容易地把它的從庫指向到其他Binlog Server就可以。更驚喜的是，由于這些Binlog Server沒有本地數(shù)據(jù)的變化，只是給下游提供日志流，相對有數(shù)據(jù)的中繼主庫來說，可以很好的解決延遲的問題。
　　我們與SkySql合作實施了Binlog Server作為一個模塊的MaxScale的插件框架。你可以閱讀這篇博客上的介紹SkySql MySQL復(fù)制，MaxScale和Binlog Server。