## 1. 主从复制 ### 1.1 异步复制 传统的MySQL复制采用主从的方式进行，可以一主一从也可以一主多从 主库执行一个事务，提交后稍后异步的传送到从库中 如果是基于语句的复制则会重新执行 如果是基于行的负责则会应用日志 同时是shared-nothing的架构，即所有服务器拥有同样的数据复制 [image:706 size:orig] ### 1.2半同步复制 MySQL也提供了一个半同步复制，即同步复制，其要求主库在commit时等待从库接受 完事务并返回确认信息后才能提交 [image:707 size:orig] ## 2. 组复制 组复制是一种可以用来部署容错系统的技术，复制组中的服务器通过massage passing来进行交互 通信层通过atomic message 和 total order message delivery来保证组内成员数据的一致性 所有的读-写(RW)操作需要组内所有成员都通过才可提交 只读(RO)事务不需要这个过程 **组复制的过程** 当事务在原始服务器上要求提交后，服务器会自动广播写值(row changed)以及相应的写集( unique identifiers of the rows) 然后一个全局的总的顺序(global total order )为该事务建立了,这意味着所有的服务器按照顺序接受到了该事务，然后所有服务器按照相同的顺序应用该事务 MGR提供一种叫做certification的步骤来解决冲突的问题 当不同服务器同时更新一行，此时则会发生冲突，这时MGR会承认第一个提交的事务，剩下的会被回滚 这也叫做distributed first commit wins 规则 [image:708 size:orig] ## 3. 组复制使用场景 MGR可以让你在组内不是全部或者大多数服务器失效时都可以保证数据库服务的可用 MGR利用一个依赖分布式失败检测器(distributed failure detector)的组成员关系服务(group membership service)来跟踪组内成员的离开(资源的离开或者是意外的离开) MGR有个分布式恢复程序(distributed recovery procedure)来确保每当有服务器加入组后数据库保持最新 从而使得我们不需要做fail-over，多主架构还可以保证主库宕机时不会阻塞更新，MGR保证数据库服务持续可用 最后需要理解的是虽然MGR可以保证数据库服务器的可用性，但是客户端的连接还是需要重新定向到另外的服务器的。想要达到这个目的，可以考虑MySQL Router，这里就不多作介绍了 如下为一些可能需要MGR的场景，这些名称我也不知道咋翻译，大家 - Elastic Replication - 一个非常流式复制的架构，服务器需要尽可能没有影响的动态的增长和减少，典型的如云上数据库服务 - Highly Available Shards - 分片是一个写扩展的功能实现，使用MGR来讲每个分片映射到不同的复制组中 - Alternative to Master-Slave replication -MGR可以作为传统主从切换的一个升级以获得更好的可用性 - Autonomic Systems - 最后你可以全新部署MGR来实现复制自动管理 ## 4. 参考资料 [https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html](https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html) [https://dev.mysql.com/doc/refman/5.7/en/group-replication-summary.html](https://dev.mysql.com/doc/refman/5.7/en/group-replication-summary.html) [https://dev.mysql.com/doc/refman/5.7/en/group-replication-examples-of-use-case-scenarios.html](https://dev.mysql.com/doc/refman/5.7/en/group-replication-examples-of-use-case-scenarios.html)