Galera 将死 — MySQL Group Replication 发布

MySQL Group Replication GA

很多同学表示昨天的从你的全世界路过画风不对，好在今天MySQL界终于有大事情发生可作为聊资。话说，当昨天小伙伴们沉浸于双12的买买买节奏中，孰料远在美国西海岸的Oracle官方放出了最新的MySQL 5.7.17版本。更为重要的是，MySQL Group Replication（下简称MGR）终于来了。

在之前的MySQL的一致性世界的文章中，Inside君已经表示腾讯基于Paxos的强一致方案虽好，但官方基于Paxos的方案早已箭在弦上，作为第三方去做这样功能的开发并不见得能有很好的收益。

什么是MGR

MGR准确来说是MySQL官方推出的高可用解决方案，基于原生复制技术，并以插件的方式提供。其包含下面的特性：

复制的管理操作变得更为自动化，还在Backup + CHANGE MASTER建复制你就out了；

通过Paxos协议提供数据库集群节点数据强一致保证，扫清了MySQL进入金融行业最后的障碍。打脸了淘宝阳振坤老师对于MySQL无法支持强一致的论调；

集群间所有节点可写入，这是很多同学梦寐以求的功能，解决了单个集群的写入性能，所有节点都能读写，不过现实还是有些残酷；

解决网络分区导致的脑裂问题，提升复制数据的可靠性。

有小伙伴也把MGR称为MySQL版的RAC。当然，这两者架构上还是有很大的差别，MGR是Share Nothing，Oracle RAC是Share Everything。

Galera寿终正寝

熟悉Galera的同学肯定会说，MGR和Gelera非常相像。而已有一部分不怕死的公司在生产环境尝试用Galera高可用解决方案，甚至是在某些银行。但他们遇到的问题却相当严重，相信真正在生产环境中使用过Galera的同学必定会同意我的观点。

相比Galera，MGR的优点在于：

MySQL官方出品，品控有保障，后续技术有支持；

MGR使用的Paxos协议，性能更好，即使MGR集群节点数再多，性能也能平稳。解决了Gelera实际只能用三个节点，网络抖动造成的性能和稳定性问题；

支持多个操作系统平台，而Galera仅支持Linux系统

先看多个主节点（multi-master）下，MGR的性能提升，即多个节点同时读写测试[1]：

当参数flow-control-mode设置为disable时，即允许集群节点间存在延迟，这时随着节点数的不断增加，MGR集群的性能可有明显地提升。若为保障读一致性，则MGR集群性能在5个节点时，几乎于单MySQL实例性能相当。

小伙伴们最关心的MGR vs Galera[2]：

无需多言，上面的测试结果基本宣告了Galera的死亡。曾经，Galera是款伟大而又引领时代的产品，死于2016年12月12日。

MGR的限制

仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测；

必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set

COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景

目前一个MGR集群最多支持9个节点

不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚

二进制日志不支持binlog event checksum

MongoDB会不会成为下一个Galera

MGR只是Oracle官方野心的第一步，Inside君更期待未来InnoDB Cluster[3]的GA。从目前的发展路线图看，未来官方会将其打造成一个分布式的文档数据库集群，对手当然是更为强大的MongoDB。但是，一个支持事务，支持行级锁与MVCC，支持数据强一致保障，基于互联网最流行与稳定的MySQL的分布式文档数据库，又有谁能拒绝这样的诱惑？

参考文献

http://mysqlhighavailability.com/zooming-in-on-group-replication-performance/

http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/

https://dev.mysql.com/doc/mysql-innodb-cluster/en/

文章转载自 开源中国社区[https://www.oschina.net]