MySQL Galera Cluster 架構最大的問題

MySQL Galera Cluster 做爲市面上比較成熟的MySQL Master-Master分佈式架構

我用了3臺作集羣， 使用wsrep_sst_method=rsync作同步配置

優勢

• 配置起來比較容易，SQL DDL DML會發送到下面全部Node，執行完畢以後才返回
• 若是node都在線，它是一個很是完美的主主架構，數據具備絕對的一致性，而且能夠分散SELECT的壓力
• 可是，這個優勢僅僅在node都在線的狀況

缺點

• 只要有重啓的行爲，該臺BinLog文件就是不完整的，在重啓期間的BinLog會徹底丟失

• 若是MySQL文件體積已經很大了，而後想新加入一臺MySQL Node，或者重啓了其中一臺節點，災難來了：

  • 它採用rsync的方式，直接去主節點上同步文件，你沒看錯，是整個文件都同步，根本沒對比，是全同步
  • 再此期間，集羣徹底中止服務，由於爲了防止數據出現更改，也就是停機 停機，

    筆者有100G左右的數據，結果就是重啓其中一臺，那麼集羣停機接近1個小時等待同步文件結束

根據官方文檔： rsync在數據同步（ SST和 IST)的時候，速度最快，可是會鎖住提供數據的節點， xtrabackup只會短暫的鎖住節點。

我曾猜測Node重啓以後，會根據主Node的BinLog的最後同步點，去拉取BinLog進行更新操做, 可是我萬萬沒想到竟然是這麼弱雞的方式，鎖住了集羣同步文件？WTF？

其實即便使用xtrabackup，也會鎖住了等待備份完成了再恢復，此時集羣是不能更新數據的，更沒法提供服務。

因此MySQL Galera Cluster 這個模式玩玩小數據，好比在1G內仍是能夠。對於大數據，仍是洗洗睡吧。

我使用 https://github.com/Xfennec/pr... 查看的rsync的整個同步過程，真是心在滴血