对于数据实时同步,其核心是须要基于日志来实现,是能够实现准实时的数据同步,基于日志实现不会要求数据库自己在设计和实现中带来任何额外的约束。git
这是常见的方案,通常来讲,中小型规模的时候,采用这种架构是最省事的。github
两个节点能够采用简单的双主模式,而且使用专线链接,在master_A节点发生故障后,应用链接快速切换到master_B节点,反之也亦然。有几个须要注意的地方,脑裂的状况,两个节点写入相同数据而引起冲突,同时把两个节点的auto_increment_increment(自增步长)和auto_increment_offset(自增起始值)设成不一样值。其目的是为了不master节点意外宕机时,可能会有部分binlog未能及时复制到slave上被应用,从而会致使slave新写入数据的自增值和原先master上冲突了,所以一开始就使其错开;固然了,若是有合适的容错机制能解决主从自增ID冲突的话,也能够不这么作,使用更新的数据版本5.7+,能够利用多线程复制的方式能够很大程度下降复制延迟,同时,对复制延迟特别敏感的另外一个备选方案,是semi-sync半同步复制,基本上无延迟,不过事务并发性能会有不小程度的损失,特别是在双向写的时候,须要综合评估再决定。sql
Galera是Codership提供的多主数据同步复制机制,能够实现多个节点间的数据同步复制以及读写,而且可保障数据库的服务高可用及数据一致性,基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(简称PXC)。数据库
目前PXC用的会比较多一些,数据严格一致性,尤为适合电商类应用,不过PXC也是有其局限性的,若是并发事务量很大的话,建议采用InfiniBand网络,下降网络延迟,由于PXC存在写扩大以及短板效应,并发效率会有较大损失,相似semi-sync半同步复制,Gelera实际只能用三个节点,网络抖动形成的性能和稳定性习惯性问题网络
经过Paxos协议提供数据库集群节点数据强一致保证,MGR准确来讲是MySQL官方推出的高可用解决方案,基于原生复制技术,并以插件的方式提供,而且集群间全部节点可写入,解决了单个集群的写入性能,全部节点都能读写,解决网络分区致使的脑裂问题,提高复制数据的可靠性,不过现实仍是有些残酷,目前尝鲜的并非不少,同时仅支持InnoDB表,而且每张表必定要有一个主键,用于作write set的冲突检测,必须打开GTID特性,二进制日志格式必须设置为ROW,用于选主与write set多线程
COMMIT可能会致使失败,相似于快照事务隔离级别的失败场景,目前一个MGR集群最多支持9个节点,不支持外键于save point特性,没法作全局间的约束检测与部分部分回滚,二进制日志不支持binlog event checksum架构
对于数据库的实时同步,阿里巴巴专门有一个开源项目,即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 双活同步复制四种解决方案,但愿对你们有所帮助,若是你们有任何疑问请给我留言,小编会及时回复你们的。在此也很是感谢你们对脚本之家网站的支持!