目录

• MySQL异步复制
• 半同步复制
• 组复制
• MGR的解决方案现在具备的特性
• MGR的解决方案目前的影响

MySQL异步复制

MySQL异步复制是主从复制过程中默认的复制模式。主从复制涉及三个线程，master I/O线程、slave I/O线程、slave sql线程。因为是异步复制，所以master事务的提交，不需要经过slave的确认，即master I/O线程提交事务后，不需要等待slave I/O线程的回复确认，master并不保证binlog一定写入到了relay log中；而slave I/O把binlog写入relay log后，由slave sql线程异步执行应用到slave mysql中，slave I/O也不需要slave sql的回复确认，并不保证relay log日志完整写入到了mysql中。

半同步复制

基于传统异步存在的缺陷，mysql在5.5版本推出半同步复制，是对传统异步复制的改进。在master事务commit前，必须确保binlog日志已经写入slave 的relay log日志中，收到slave给master的响应后，才能进行事务的commit。但是后半部分的relay log到sql线程仍然属于异步执行。

组复制

基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。

由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。

MGR环境下，服务器数量必须是3台以上，并且是单数，实现2/n+1的算法。

一个复制组由若干个节点(数据库实例)组成，组内各个节点维护各自的数据副本(Share Nothing)，通过一致性协议实现原子消息和全局有序消息，来实现组内实例数据的一致。

MGR的解决方案现在具备的特性

数据一致性保障：确保集群中大部分节点收到日志

多节点写入支持：多写模式下支持集群中的所有节点都可以写入（但是考虑1到高并发场景下，保证数据高度一致性，生产并没有选择多主写入，使用单主集群）

Fault Tolerance: 确保系统发生故障（包括脑裂）依然可用，双写对系统无影响

MGR的解决方案目前的影响

• 仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测；
• 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set
• COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景
• 目前一个MGR集群最多支持9个节点
• 不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚
• 二进制日志不支持binlog event checksum

到此这篇关于Mysql主从三种复制模式(异步复制,半同步复制,组复制)的文章就介绍到这了,更多相关Mysql主从复制内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！