云计算服务
服务器租用
DDOS 防护
虚拟主机
域名服务
基础设施
关于我们
传统的MySQL复制采用主从的方式进行，可以一主一从也可以一主多从主库执行一个事务，提交后稍后异步的传送到从库中
如果是基于语句的复制则会重新执行，如果是基于行的负责则会应用日志，同时是shared-nothing的架构，即所有服务器拥有同样的数据复制。
传统的MySQL主从复制架构是MySQL保持数据一致性的最基本架构，如下图所示，一主一从架构，从库给主库发起读数据请求后，主库会通过 dump线程把binlog日志文件推送给从库，从库的I/O线程把接收到数据更新到relay log，之后从库的SQL线程把relay log应用为binlog日志，直到主库与从库的binlog日志文件完全数据一致，达到主从同步 。
接下来我们看一下MySQL 异步复制，如下图所示，一主两从架构，应用发来的事务请求，经过执行之后写入binlog，主库master把binlog日志推送给从库 salve1和slave2 ，主库不需要等到从库是否成功更新数据到relay log，主库直接提交事务即可。这种模式牺牲了数据一致性，不能很好保证主从数据一致性。
模拟异步复制场景举例，如下图所示，三个人对话，一个人在不停歇的演讲，不需要知道两个听众是否听懂，听众也不需要做出回应，等演讲完毕，有可能听众没听懂，最终大家认知到信息可能不一致，为了解决上述问题MySQL5.5.8 就有了半同步复制。
MySQL也提供了一个半同步复制，即同步复制，其要求主库在commit时等待从库接受 完事务并返回确认信息后才能提交
接下来看一下 MySQL的半同步复制，如下图所示，一主两从架构，应用发来的事务请求，在主库执行后写入binlog，主库master把binlog日志推送给从库 salve1和slave2 ，半同步主库需要等待其中任意一个从库更新数据到relay log成功并且告知主库，主库才提交事务，这样保证至少有一个从库同步上数据了，也缩短了延迟时间，保证了数据安全。
模拟半同步复制场景举例，如下图所示，三个人对话，一个人在不停歇的演讲，任意一个听众回应听懂了，演讲者就继续往下说，否则停止演讲，最后等演讲结束，至少一听众听懂演讲者的意思，保证信息传递一致性，这种复制模式也存在两个问题：
1）MySQL无法自动切换，需要借助外力切库，运维复杂。
2）从库Slave的读压力太大会导致复制延迟不断增加。
MySQL5.7版本的MGR技术可以解决上述问题。至此MGR技术诞生！
组复制是一种可用于实现容错系统的技术。 复制组是一个通过消息传递相互交互的 server 集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制。 这些是非常强大的功能,我们可以据此架构设计更高级的数据库复制解决方案。
MySQL 组复制以这些功能和架构为基础,实现了基于复制协议的多主更新。
复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。换句话说,对于任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同的更改,以确保组内一致。在不同 server 上并发执行的事务可能存在冲突。 根据组复制的冲突检测机制,对两个不同的并发事务的写集合进行检测。如在不同的 server 成员执行两个更新同一行的并发事务,则会出现冲突。排在最前面的事务可以在所有 server 成员上提交,第二个事务在源 server 上回滚,并在组中的其他 server 上删除。 这就是分布式的先提交当选规则。
.png)
.png)
