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