组复制是一种实现容错系统的技术。复制组是一个服务器集，每个服务器都拥有整个数据副本（共享 nothing 复制方案），并通过消息传递与其他服务器交互。通信层提供了一些保证，如原子消息和总顺序消息传递。这些建议性质可以转化为非常有用的抽象，可以用于构建更高级的数据库复制解决方案。

MySQL 组复制基于这些建议性质和抽象，并实现了多源更新处处复制协议。一个复制组由多个服务器组成，每个服务器都可以独立执行事务。但是，所有读写事务只有在群组批准后才能提交。在其他字样，这意味着对于任何读写事务，群组需要决定是否提交，所以提交操作不是起源服务器的单方面决策。只读事务不需要群组协调，并且可以立即提交。

当读写事务在起源服务器准备提交时，该服务器原子广播写值（被更改的行）和相应的写集（更新了的行的唯一标识符）。由于事务通过原子广播发送，或者所有服务器都收到事务，或者没有收到。如果收到，它们将在其他事务之前的顺序中收到。因此，所有服务器都收到相同的事务顺序，并且为事务建立了一个全局总顺序。

然而，在不同的服务器上并发执行事务可能会出现冲突。检测这些冲突的过程称为认证。在认证过程中，冲突检测是在行级别进行的：如果两个并发的事务，分别在不同服务器上执行，并且更新同一行，那么就存在冲突。冲突解决程序规定，在所有服务器上，先于其他事务提交的事务commit，而后的事务abort，并因此在起源服务器上回滚，并在其他服务器组中被删除。例如，如果t1和t2在不同站点并发执行， ambos修改同一行，并且t2排在t1前，那么t2就赢得了冲突，t1将被回滚。这实际上是一种分布式的“先提交”规则。需要注意的是，如果两个事务之间存在冲突的可能性高于平均值，那么最好将它们启动在同一个服务器上，以便它们可以同步使用本地锁管理器，而不是由于认证而被回滚。

为了应用和外部化证书事务，Group Replication 允许服务器偏离事务的 agreed 顺序，如果这不破坏一致性和有效性。Group Replication 是一种最终一致系统，这意味着当 incoming 交通流量减慢或停止时，所有组成员都将拥有相同的数据内容。在流量流动期间，事务可以在略微不同的顺序中外部化，也可以在一些成员上外部化，而其他成员还没有。例如，在多主模式下，一個本地事务可能会在证书后立即外部化，而一个远程事务，即使在全球顺序中排在前面，也还没有被应用。这是在证书过程中确定了事务之间无冲突的情况下允许的。在单主模式下，在主要服务器上，有一小 chance Concurrent，非冲突的本地事务可能会在不同的顺序中提交和外部化，而在全球顺序中由 Group Replication 承认。Secondary 服务器上，因为不接受来自客户端的写入，事务总是按照 agreed 顺序提交和外部化。

以下图像描绘了 MySQL Group Replication 协议，并将其与 MySQL 复制（或甚至 MySQL 半同步复制）进行比较，可以看到一些差异。为了保持清晰，某些 underlying_consensus 和 Paxos 相关消息从这幅图像中被省略。

图 20.3 MySQL Group Replication 协议