MySQL 双活同步复制的四种方案_咸鱼的梦想专栏-CSDN博客_mysql双机同步复制

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

基于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