目前，xx網資料庫採用mysql AB複製進行災備，這種方法也是目前大多數公司所使用的。

不過，因mysql AB複製是非同步的，也就是說主庫並不關心備庫是否接收到日誌並應用，所以可能會發生備庫和主庫的資料有延時的現象。舉一個極端的例子，在主庫業務量很忙的情況下，假設主庫突然當機，這時候可能會發生主庫有部分日誌沒來得及傳到備庫的現象，那麼備庫就會比主庫少資料，如果這時候啟用備庫接管任務，勢必會造成部分資料丟失。這對於一個金融類的系統，是絕不允許的。

那麼對於這個問題，大名鼎鼎的oracle是怎麼做的呢？Dataguard是oracle的主從同步， dataguard有三種模式：最大效能、最大可用和最大保護。最大保護模式可以嚴格保證資料0丟失，但這是有代價的。在最大保護模式下，主庫向備庫傳日誌，備庫接收日誌並應用後，備庫再給主庫發一個成功應用日誌的通知，主庫接到這個成功應用的通知後，主庫才能繼續新的交易，否則主庫會一直等待備庫的這個成功應用日誌的通知。所以說，dataguard的最大保護模式是透過損失“效能”來獲取資料的絕對“安全”的。一般來說，很少有人把datagurad置於這種模式，因為效能太差。

回到mysql的AB複製，是否也有像oracle dataguard這種最大保護模式呢？答案是否定的，從mysql 5.5以後，才有一個半同步的功能，但不是真正的同步，也就是說主庫也會等待備庫傳送日誌應用成功的通知，但如果主庫等了10秒還是沒接到這個通知，那麼主庫也就不等了，繼續下一個交易，所以這個同步算作是偽同步吧，也不能保證主從資料庫在同一時刻資料嚴格一致。

針對mysql主從資料庫有延時的問題，筆者也翻閱了大量的資料，最後驚訝於mysql的災備方案種類繁多，真是“百花齊放、百家爭鳴”。接下來，筆者就淺談一下這些方案，也算是一個拋磚引玉，和大家共同探討。

方案	描述	缺點	資料零丟失	日誌補償	自動ip漂移	故障切換時長	費用情況	本人是否做過該實驗
mysql AB複製	單向資料同步		不支援	不支援	不支援	DBA手工切換	免費	做過
mysql AB+keepalived	雙主	冗餘造成腦裂，主從資料不一致	不支援	不支援	支援	秒級	免費	做過
mysql+drbd+heartbeat	這種mysql主從同步不是依賴的傳輸日誌，而是drbd的塊複製，主從資料是時時同步的，	缺點是DBA不能手工干預（binlog是可以手工干預的），並且備庫的資料在同步時不能讀取。這對於mysql讀寫分離的架構造成了困擾。	支援	不支援（不用日誌）	支援	秒級	免費	做過
MHA	需要至少三臺機器，其中一臺機器做為監控器，用來監控主庫的狀態，當主庫當機後，監控器會找一個接收到主庫日誌最多的備庫，並將其選為新的主庫。	也不能保證資料零丟失	不支援	支援	支援	秒級	免費	做過
MMM	該方案筆者沒有做過，不過感覺和MHA方案很像。		不支援	不支援	支援	秒級	免費	沒做過
MySQL cluster （同步）	MySQL cluster是資料同步複製的完美解決方案，每次事務都是雙commit，所以說叢集中的各個節點資料是完全一致的，不會出現腦裂的情況。如果叢集中的一個節點壞了，等修復好後，資料會自動同步。	該叢集的資料儲存量不能超過叢集中所有節點記憶體之和除以2.5。比如我MySQL cluster有5個節點，這五個節點的記憶體加起來是64G，那麼資料儲存量不能超過30G（64G/2.5~30G）。該方案費用太貴，不差錢的公司可以考慮。	支援	支援	支援	秒級	免費	沒做過
MySQL+shared Disk 雙機主備	此方案的的資料在共享儲存上，所以資料只有一份，沒有冗餘。此外，這個方案的主備兩個節點平時只能一個節點（active）對外提供服務；另外一個節點（passive）的mysql服務是關閉狀態的，只有發生故障切換時才啟動。	資料沒有冗餘，平時只有一個節點對外提供服務。	不支援	不支援	不支援	手工	免費	沒做過
DRBD+Pacemaker+Corosync	對於這個方案不解釋，還沒來得及研究。
mysql+transfer	這個方案來自由淘寶網核心DBA丁奇。他主要的思想是對從庫啟用了多執行緒（原生mysql的AB複製的從庫一直都是單執行緒的），來解決備庫發生延遲的問題	如果有問題，就得求爺爺告奶奶的請淘寶的丁奇來出山。						沒做過
愛可生HA高可用方案（商業軟體）	1、該方案是把binlog日誌放在共享儲存上（共享儲存10G大小就夠了），這樣當master資料庫當機後，slave資料庫讀取共享儲存上的binlog來追平和master資料庫的差異，從而保證slave的資料和master當機時的資料強一致性，做到了零資料丟失。 2、該方案是需要向愛可生公司購買該HA軟體的。費用大概是4萬的樣子，具體可向該司銷售諮詢。	付費（4萬的樣子）	支援	支援	支援	秒級	付費	沒做過
自己想的一個方案	可以把binlog日誌放在共享儲存上，當主庫當機後,DBA從共享儲存上獲取binlog,手工補齊備庫的中繼日誌	主庫當機後，需要DBA手工干預補齊備庫的日誌。	支援	支援	不支援	手工恢復	免費	沒做過

看到上面這些專門針對mysql災備的方案，是不是感嘆方案太多，不知用哪個好。另外，mysql的儲存引擎也有好多種，每種各有利弊，所以學mysql也是一件不容易的事情。

結論：

1、針對mysql AB複製資料延遲的問題，可能幾乎不會發生，因為我們的伺服器在公司內網環境，網路IO或許不是瓶頸。所以備庫丟資料的問題可能會是我們杞人憂天了。

不過，最近我透過淘寶核心DBA丁奇的博文，重新認識了mysql AB複製延遲問題產生的原因，他說延遲是由於mysql 主庫是多執行緒進行事務交易，但是備庫只用了單執行緒。為什麼Mysql備庫不採用多執行緒呢，因為備庫多執行緒的話，無法保證備庫應用日誌順序的（update和insert兩條語句，誰先執行，誰後執行，造成的結果可能會是不一樣的）。所以，原生的官方Mysql為了保守起見，備庫只用單執行緒來同步日誌（單執行緒能保證順序應用日誌）；

2、如果不考慮費用問題，可以採用上表中的愛可生的商業軟體來保證資料零丟失；

3、自己想了一個方案（見上表），就是把binlog放在共享儲存上，當主庫當機不可用後，DBA獲取共享儲存上的binlog，手工在備庫追平。

4、可以用上述的Mysql cluster，可以保證零資料丟失，但是該方案用的機器多，費用貴，而且資料儲存量不能超過所有伺服器記憶體之和除以2.5。

天下就沒有完美的事情！

以上，是我對Mysql AB複製資料丟失風險的問題闡述，大家可以一起探討。

你還可以參見以下連結來了解詳細資訊：

http://blog.itpub.net/28916011/viewspace-1719675/

關於對我司xx網資料庫發生極端問題的猜想

相關文章