Java自学者论坛

 找回密码
 立即注册

手机号码,快捷登录

恭喜Java自学者论坛(https://www.javazxz.com)已经为数万Java学习者服务超过8年了!积累会员资料超过10000G+
成为本站VIP会员,下载本站10000G+会员资源,会员资料板块,购买链接:点击进入购买VIP会员

JAVA高级面试进阶训练营视频教程

Java架构师系统进阶VIP课程

分布式高可用全栈开发微服务教程Go语言视频零基础入门到精通Java架构师3期(课件+源码)
Java开发全终端实战租房项目视频教程SpringBoot2.X入门到高级使用教程大数据培训第六期全套视频教程深度学习(CNN RNN GAN)算法原理Java亿级流量电商系统视频教程
互联网架构师视频教程年薪50万Spark2.0从入门到精通年薪50万!人工智能学习路线教程年薪50万大数据入门到精通学习路线年薪50万机器学习入门到精通教程
仿小米商城类app和小程序视频教程深度学习数据分析基础到实战最新黑马javaEE2.1就业课程从 0到JVM实战高手教程MySQL入门到精通教程
查看: 496|回复: 0

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

[复制链接]
  • TA的每日心情
    奋斗
    2024-11-24 15:47
  • 签到天数: 804 天

    [LV.10]以坛为家III

    2053

    主题

    2111

    帖子

    72万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    726782
    发表于 2021-7-9 20:18:57 | 显示全部楼层 |阅读模式

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

     

    基于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 双活同步复制四种解决方案,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对脚本之家网站的支持!

    哎...今天够累的,签到来了1...
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    QQ|手机版|小黑屋|Java自学者论坛 ( 声明:本站文章及资料整理自互联网,用于Java自学者交流学习使用,对资料版权不负任何法律责任,若有侵权请及时联系客服屏蔽删除 )

    GMT+8, 2024-12-23 09:54 , Processed in 0.356925 second(s), 28 queries .

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表