MySQL Group Replication GA

对于数据实时同步,其核心是需要基于日志来实现,是可以实现准实时的数据同步,基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束。

在以前,数据库的集群配置一直很难,难点在于MySQL主从结构的高可用和读写分离。万幸的是,Galera/GR的出现,让整个集群的配置都极大程度地简化了。

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

基于MySQL原生复制主主同步方案

以下是一个简单的MySQL集群拓扑图:

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

这是常见的方案,一般来说,中小型规模的时候,采用这种架构是最省事的。

澳门新葡萄京所有网站 1

什么是MGR

两个节点可以采用简单的双主模式,并且使用专线连接,在master_A节点发生故障后,应用连接快速切换到master_B节点,反之也亦然。有几个需要注意的地方,脑裂的情况,两个节点写入相同数据而引发冲突,同时把两个节点的auto_increment_increment和auto_澳门新葡萄京所有网站,increment_offset设成不同值。其目的是为了避免master节点意外宕机时,可能会有部分binlog未能及时复制到slave上被应用,从而会导致slave新写入数据的自增值和原先master上冲突了,因此一开始就使其错开;当然了,如果有合适的容错机制能解决主从自增ID冲突的话,也可以不这么做,使用更新的数据版本5.7+,可以利用多线程复制的方式可以很大程度降低复制延迟,同时,对复制延迟特别敏感的另一个备选方案,是semi-sync半同步复制,基本上无延迟,不过事务并发性能会有不小程度的损失,特别是在双向写的时候,需要综合评估再决定。

1.MySQL中间件:对MySQL
Server的读写操作进行路由(即读写分离);分库分表(sharding)

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

基于Galera replication方案

  • (1).MySQL
    Router:MySQL官方提供的轻量级MySQL代理(路由),只提供读写分离功能,前身为SQL
    Proxy。
  • (2).ProxySQL:类似于MySQL
    Router,轻量级MySQL代理,提供读写分离功能,也支持一些sharding功能。有percona版和官方版两个版本。
  • (3).MaxScale:MariaDB的中间件,和MySQL Router、ProxySQL类似。
    • 这三者类似,都是轻量级数据库中间件。
  • (4).Amoeba、Cobar、MyCAT:提供很多功能,最主要的功能包括读写分离、sharding。
    • 这三者的渊源较深,都是开源的。Amoeba后继无人,于是Cobar出来,Cobar后继无人,加上2013年出现了一次较严重的问题,于是MyCAT站在Cobar的肩膀上出来了。
  • 复制的管理操作变得更为自动化,还在Backup + CHANGE
    MASTER建复制你就out了;

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

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

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

Galera是Codership提供的多主数据同步复制机制,可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据一致性,基于Galera的高可用方案主要有MariaDB
Galera Cluster和Percona XtraDB Cluster。

2.MySQL主从复制的高可用:至少要实现主从切换或故障时选举新master节点

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

目前PXC用的会比较多一些,数据严格一致性,尤其适合电商类应用,不过PXC也是有其局限性的,如果并发事务量很大的话,建议采用InfiniBand网络,降低网络延迟,因为PXC存在写扩大以及短板效应,并发效率会有较大损失,类似semi-sync半同步复制,Gelera实际只能用三个节点,网络抖动造成的性能和稳定性习惯性问题

  • (1).MMM:淘汰了,在一致性和高并发稳定性等方面有些问题。
  • (2).MHA:有些人还在用,但也有些问题,也是趋于淘汰的MySQL主从高可用方案。
  • (3).Galera:引领时代的主从复制高可用技术。
  • (4).MariaDB Galera Cluster:MariaDB对Galera的实现。
  • (5).PXC:Percona XtraDB
    Cluster,是Percona对Galera的自我实现,用的人很多。
  • (6).GR:Group Replication,MySQL官方提供的组复制技术(MySQL
    5.7.17引入的技术),基于Paxos算法。

    • MariaDB Galera
      Cluster、PXC、GR是类似的,都各有优点。但GR是革命性的,基于原生复制技术,据传很多方面都优于PXC。
    • MariaDB Galera
      Cluster、PXC、GR为了安全性和性能考虑,做出了很多强制性的限制。例如基于GTID复制、只能InnoDB表,每表都必须有主键等。要使用它们提供主从复制的高可用,必须要了解它们的各项限制。

澳门新葡萄京所有网站 2

基于Group Replication方案

Galera寿终正寝

通过Paxos协议提供数据库集群节点数据强一致保证,MGR准确来说是MySQL官方推出的高可用解决方案,基于原生复制技术,并以插件的方式提供,并且集群间所有节点可写入,解决了单个集群的写入性能,所有节点都能读写,解决网络分区导致的脑裂问题,提升复制数据的可靠性,不过现实还是有些残酷,目前尝鲜的并不是很多,同时仅支持InnoDB表,并且每张表一定要有一个主键,用于做write
set的冲突检测,必须打开GTID特性,二进制日志格式必须设置为ROW,用于选主与write
set

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

COMMIT可能会导致失败,类似于快照事务隔离级别的失败场景,目前一个MGR集群最多支持9个节点,不支持外键于save
point特性,无法做全局间的约束检测与部分部分回滚,二进制日志不支持binlog
event checksum

相比Galera,MGR的优点在于:

基于canal方案

  • MySQL官方出品,品控有保障,后续技术有支持;

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

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

对于数据库的实时同步,阿里巴巴专门有一个开源项目,即otter来实现分布式数据库的同步复制,其核心思想仍然是通过获取数据库的增量数据日志,来进行准实时的同步复制。因此otter本身又依赖于另外一个开源项目即canal,该项目重点则是获取增量数据库同步日志信息。

先看多个主节点(multi-master)下,MGR的性能提升,即多个节点同时读写测试[1]:

当前otter的重点是实现mysql间的数据库同步复制,基本即利用的类似技术来实现两个mysql数据库间的双向同步数据库复制。要注意这个双向本身指既可以A-B,也可以从B-A,在某个时间节点本身是单向的。

澳门新葡萄京所有网站 3

主从复制分成三步:

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

master将改变记录到二进制日志(binary log)中;

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

slave将master的binary log events拷贝到它的中继日志(relay log);

澳门新葡萄京所有网站 4

slave重做中继日志中的事件,将改变反映它自己的数据。

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

canal原理相对比较简单:

MGR的限制

canal模拟mysql slave的交互协议,伪装自己为mysql slave,向mysql
master发送dump协议

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

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

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

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

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

  • 二进制日志不支持binlog event checksum

mysql master收到dump请求,开始推送binary
log给slave(也就是canal)canal解析binary log对象(原始为byte流)

MongoDB会不会成为下一个Galera

更多参考

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

总结

参考文献

以上所述是小编给大家介绍的MySQL
双活同步复制四种解决方案,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持!

稿源:  InsideMySQL