进入MGR细节之前，我们先了解下相关的概念和复制技术的运行机制。本节帮我我们了解什么是组复制需要的，以及经典的MySQL异步复制和组复制的区别。

1.Primary-Secondary复制

传统的MySQL复制提供了一个简单Primary-Secondary方法，由一个primary(master)和一个或多个secondary(slave)节点。主节点进行事务的执行和提交，并异步发送给副节点再次执行或应用。这是一个shared-nothing系统，默认情况下所有的服务器都有完整的数据副本。如下图所示：

还有一种半同步复制，只需在协议中增加一个同步的步骤。这意味着主节点在提交时将等待，直到收到复节点收到事务的确认信息，只有这样主节点才会继续提交事务。如下图所示：

上述图片中，斜向的箭头代表服务器之间以及服务器和客户端应用间的消息交换。

2.组复制(Group Replication)

组复制是一项可用来实现容错系统的技术。复制组是相互间可进行消息传递的服务器的集合。通信层提供了例如原子化消息、完全顺序的消息传递等一系列保证。这些属性为建立更高级的数据库复制解决方案提供了极其由用的抽象。

MGR建立在这些属性和抽象之上，实现了多主更新任意副本的协议。本质上，一个复制组由多个服务器组成，复制组中每个服务器都可以独立执行事务。但所有读写(RW)事务只有在得到组认可后才能提交。只读(RO)事务不需要组内协商就能立即提交事务。换句话说，对于RW事务，复制组需要决定是否要提交这个事务，因此提交操作并不是由发起事务的服务器单方面决定的。准确来说，当发起事务的服务器准备提交事务的时候，这个服务器或自动广播这个写操作，然后全局事务顺序被建立，最终，所有服务器收到相同事务顺序下相同的写操作。因此，所有服务器以相同顺序实现了数据库更新，因此组内服务器可以保持一致性。

但是，在不同服务器上同时执行的事务之间可能会有冲突，这些冲突会被certification进程检测到，certification进程会监控两个同时进行的不同事务的写操作结果集。如果两个同时进行的事务被不同的服务器执行，且更新同一行数据，那么就会发生冲突。解决方案流程是：事务序列中先被提交的事务被执行，而后提交的事务被终止，这样后提交事务的服务器将会回滚，而其他服务器将丢失这个被终止的事务。这实际上也是一个分布式的提交顺序优先规则。

如下图所示：

最终，组复制是一个shared-nothing的复制模式，每个服务器都有数据的备份。

上图描绘了MGR协议，把它和MGR复制技术相比较，我们可以看到不同点。需要指出的是，为清晰度起见，图片中与共识和Paxos相关的消息流没有被画出。