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在数据同步(SSTIST)的时候,速度最快,但是会锁住提供数据的节点,xtrabackup只会短暂的锁住节点。

我曾猜想Node重启之后,会根据主NodeBinLog的最后同步点,去拉取BinLog进行更新操作, 但是我万万没想到居然是这么弱鸡的方式,锁住了集群同步文件?WTF?

其实即使使用xtrabackup,也会锁住了等待备份完成了再恢复,此时集群是不能更新数据的,更无法提供服务。

所以MySQL Galera Cluster 这个模式玩玩小数据,比如在1G内还是可以。对于大数据,还是洗洗睡吧。

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

相关推荐