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的整个同步过程，真是心在滴血