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