MySQLPatch–MirroredBinlogs(FromGoogle)

這幾天看了不少Google針對于MySQL開發(fā)的google-mysql-tools，找到一個很有意思的Patch：MirroredBinlogs。 這個Patch通過修改MySQL Replication中Slave IO線程的實現(xiàn)，讓該線程在寫入relay log的同時，再Mirror了一份與Master端完全一模一樣binlog。這里所說

這幾天看了不少Google針對于MySQL開發(fā)的google-mysql-tools，找到一個很有意思的Patch：MirroredBinlogs。

這個Patch通過修改MySQL Replication中Slave IO線程的實現(xiàn)，讓該線程在寫入relay log的同時，再Mirror了一份與Master端完全一模一樣binlog。這里所說的一模一樣不僅僅是binlog的內(nèi)容完全一樣，同時還包括binlog的文件名。也就是說，該線程在Slave端完全copy了一份Master的binlog日志。

在該 Patch 的描述中，該 Patch 產(chǎn)生的初衷是為了解決Slave與Master之前的順利切換，并保證切換之后其他Slave仍然能夠正常從新的Master繼續(xù)進(jìn)行復(fù)制。

作者設(shè)想了如下一個場景：
在 Hierarchical Replication（級聯(lián)復(fù)制）環(huán)境中，第一層是有一臺 Master ，第二層是兩臺 Slaves ，這兩臺Slave主要作用是作為第三層更多 Slave 的 Master 。也就是，第二層的兩臺 Slave 的角色在整個集群環(huán)境中是一個復(fù)制代理。如果我們使用的是普通的MySQL，那么中間代理層的兩臺Slave之間的binlog日志可能會有較大差異，因為兩臺Slave自身也會有產(chǎn)生binlog的event。而通過使用該Patch之后，通過 Slave IO 線程將第一層中 Master 的binlog完全一模一樣的copy到第二層的 Slave 上面，而使這一層的binlog完全一致。這樣，當(dāng)?shù)诙拥膬膳_復(fù)制代理機器中的一臺Crash之后，可以很容易的將第三層中以 前面 Crash 的 Slave 作為 Master 的所有 Slave 可以很容易的切換 Master 到另外一臺 代理 Slave 上面。

只不過，開發(fā)者已經(jīng)停止了該Patch的更新，并將該Patch整合到了一個新的叫 GlobalTransactionIds（MySQL Hierarchical Replication & Global Group IDs）的Patch中，只不過該Patch還正在開發(fā)中。從 Google 在 GlobalTransactionIds 的介紹中可以看到比其他 Patch 更為詳細(xì)的一些說明，不知道是否算是對該 Patch 比較重視的一個表現(xiàn)呢？ 希望不是我的一廂情愿吧。

自己目前還沒有詳細(xì)測試過 MirroredBinlogs 這個 Patch，也不知道是否奏效，不過我想 Google 應(yīng)該不會在技術(shù)這種事情上拿自己的名聲和我們開這種玩笑吧，哈哈。如果有哪位朋友已經(jīng)做過相關(guān)的測試的話，就 Share 一下效果吧…

原文地址：MySQL Patch – MirroredBinlogs (From Google), 感謝原作者分享。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com