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