皮皮机器猫
作者皮皮机器猫·2019-07-22 17:47
数据库管理员·福建亿榕

了解 MySQL 双活同步复制四种方案

字数 2088阅读 9664评论 1赞 6

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

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

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

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

基于Galera replication方案**

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

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

基于Group Replication方案**

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

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

基于canal方案**

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

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

主从复制分成三步:

master 将改变记录到二进制日志 (binary log) 中(这些记录叫做二进制日志事件, binary log events ,可以通过 show binlog events 进行查看);

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

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

canal 原理相对比较简单:

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

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

更多参考 https://github.com/alibaba/canal

作者:冯帅,从事多年MySQL相关工作,熟悉高可用、容灾架构设计,擅长MySQL大规模运维管理优化,企业数据库维护等经验。对于MySQL双活方案设计有丰富的经

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论1 条评论

lubolubo其它汤岗子医院
2019-07-24 13:24
好文章!
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广