MySQL组复制MGR（一）-- 技术概述
（一）复制技术的发展
MySQL的复制技术主要经历了异步主从复制，半同步复制，组复制(Group Replication)3个阶段。
（1）传统的异步主从复制
传统的MySQL提供了一种简单的主从复制方法。有1个主服务器(master)，有1个或多个从服务器(slave)，主服务器执行事务，然后提交，从服务器异步接收日志，并重新应用日志。
该架构存在的问题有：如果主服务器/数据库crash了，日志没有完成传送到备库，那么当备库切换为主库的时候，可能存在数据丢失的风险。
异步复制架构如下：
图1.MySQL Asynchronous Replication
（2）半同步复制
半同步复制向同步协议添加一个步骤，这意味着主库在执行提交的时候，需要等待从库确认已经接收到事务，才能进行提交。
该架构存在的问题有：主库必须等待备库接收到日志并返回响应才算完成事物，造成了主库的延迟，这个延迟最少是一个TCP/IP往返的时间，因此半同步复制最好在延迟低的网络中使用
半同步复制架构如下：
图2.MySQL semisynchronous Replication
（3）组复制
组复制是一种可用于实施容错系统的技术。组复制是一组服务器，每个服务器都有自己的完整数据副本，并通过消息传递相互交互。一个组复制由多个服务器组成，该组中的每个服务器都可以随时独立执行事务。但是，所有读写事务仅在获得组批准后才提交，换句话说，对于任何读写事务，该组都需要确定提交，因此提交操作不是来自原始服务器的单方面决定。只读事务不需要组内协调，可以立即提交。
组复制可以是单主模式和多主模式，多主模式意味所有组成员都可以执行写操作，这样就可能存在事务冲突，根据组复制冲突监测机制，如果存在两个不同的server成员更新同一行的并发事务，排在最前面的可以在所有server成员上提交，第二个事务在源server上回滚，并在组中的其它server上删除。
图3.MySQL Group Replication
关于三种复制技术，个人觉得：异步复制提供了主从方案，降低了单节点运行数据库的风险；后续的半同步复制是异步主从复制的加强，解决了数据丢失的风险，但是依然存在网络延迟，切换麻烦的问题(例如10个节点，1主9从，主节点宕机，当把一个从节点提升为主节点后，其它节点需要手动修改master)，而组复制则拥有了自动故障转移failover的能力，当主节点发生故障(单主模式才需考虑)时，组内部会自动选择主节点。
（二）组复制的容错能力
组复制建立在Paxos分布式算法之上，以提供服务器之间的分布式协调，因此，他需要大多数服务器处于活动状态才能正常工作。如果有n台服务器，最多允许故障的服务器数量为f，那么n与f之间的关系为：n=2f+1。或许这么看有些难以理解，可以看下面的关系：
| 组复制服务器数量 | 多数 | 允许故障的服务器数量 |
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
对组复制有了一定的了解，接下来，我们一起来搭建组复制。。。