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