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

MySQL 组复制基于这些属性和抽象，并实现了一个多源更新所有地方的复制协议。复制组由多个服务器组成，每个服务器在组中可以独立执行事务。然而，所有读写事务只有在组批准后才能提交。换言之，对于任何读写事务，组需要决定是否提交，因此提交操作不是来自原始服务器的单方面决定。只读事务不需要组内协调，可以立即提交。

当读写事务准备提交到原始服务器时，服务器原子广播写入值（更改的行）和相应的写入集（更新的行的唯一标识符）。由于事务是通过原子广播发送的，因此所有服务器在组中都将收到事务，或者没有服务器收到。如果它们收到事务，那么它们都将以相同的顺序收到事务，以建立全局总顺序。

然而，在不同的服务器上执行的并发事务之间可能存在冲突。这些冲突通过检查和比较两个并发事务的写入集来检测，在一个称为 认证 的过程中。在认证过程中，冲突检测是在行级别进行的：如果两个并发事务在不同的服务器上执行，并更新同一行，那么存在冲突。冲突解决程序规定，第一个事务提交所有服务器，而第二个事务回滚，并在原始服务器上回滚，并被其他服务器在组中删除。例如，如果 t1 和 t2 在不同的站点上并发执行，均更改同一行，并且 t2 排序在 t1 之前，那么 t2 胜出冲突，t1 回滚。这实际上是一个分布式的“先提交者获胜”规则。注意，如果两个事务经常冲突，那么在同一服务器上启动它们是一个良好的做法，以便它们在本地锁定管理器上同步，而不是由于认证而回滚。

对于应用和外部化认证事务，组复制允许服务器偏离事务的同意顺序，以便不破坏一致性和有效性。组复制是一个最终一致性系统，这意味着只要入流量减少或停止，所有组成员都将拥有相同的数据内容。在流量流动时，事务可以以略有不同的顺序外部化，或者在某些成员上外部化，而不是其他成员。例如，在多主模式下，局部事务可能会在认证后立即外部化，尽管远程事务在全局顺序中排在前面。只要认证过程已经确定事务之间没有冲突，这就是允许的。在单主模式下，在主服务器上，有小概率的并发本地事务可能会以不同的顺序提交和外部化。 在次要服务器上，不接受客户端写入的事务总是以同意顺序提交和外部化。

下图描述了 MySQL 组复制协议，并与 MySQL 复制（或 MySQL 半同步复制）进行比较，可以看到一些差异。一些底层共识和 Paxos 相关消息已从图中删除，以便清晰。

图 20.3 MySQL 组复制协议