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

MySQL 组复制建立在这些属性和抽象之上，并实现了一个多源更新到所有位置的复制协议。复制组由多个服务器组成，组中的每个服务器都可以随时独立执行事务。但是，所有读写事务只有在获得组批准后才能提交。换句话说，对于任何读写事务，组都需要决定它是否提交，因此提交操作不是来自源服务器的单方面决定。只读事务不需要在组内进行协调，并且会立即提交。

当读写事务准备在源服务器上提交时，服务器会原子地广播写入值（已更改的行）和相应的写入集（已更新行的唯一标识符）。由于事务是通过原子广播发送的，因此组中的所有服务器要么都收到事务，要么都不收到。如果它们接收了事务，那么它们都以相对于其他先前发送的事务的相同顺序接收。因此，所有服务器都以相同的顺序接收相同的交易集，并且为交易建立了全局总顺序。

但是，在不同服务器上并发执行的事务之间可能存在冲突。这种冲突通过检查和比较两个不同并发事务的写入集来检测，这个过程称为认证。在认证期间，冲突检测在行级别进行：如果两个在不同服务器上并发执行的事务更新了同一行，那么就会出现冲突。冲突解决过程规定，在所有服务器上提交的第一个排序的事务，而第二个排序的事务将中止，因此在源服务器上回滚并在组中的其他服务器上丢弃。例如，如果 t1 和 t2 在不同的站点并发执行，并且都更改了同一行，并且 t2 在 t1 之前排序，那么 t2 将赢得冲突，而 t1 将回滚。这实际上是一个分布式的第一个提交者获胜规则。请注意，如果两个事务经常发生冲突，那么最好在同一台服务器上启动它们，在那里它们有机会在本地锁管理器上同步，而不是由于认证而被回滚。

为了应用和外部化已认证的事务，组复制允许服务器偏离已协商的事务顺序，只要不破坏一致性和有效性即可。组复制是一个最终一致性系统，这意味着一旦传入流量减慢或停止，所有组成员都会拥有相同的数据内容。当流量正在流动时，事务可以在略微不同的顺序外部化，或者在其他成员之前在某些成员上外部化。例如，在多主模式下，本地事务可能会在认证后立即外部化，尽管全局顺序中更早的远程事务尚未应用。当认证过程确定事务之间不存在冲突时，这是允许的。在单主模式下，在主服务器上，并发、非冲突本地事务可能会以与组复制协商的全局顺序不同的顺序提交和外部化，这种可能性很小。在从服务器上，从服务器不接受来自客户端的写入，事务始终按协商的顺序提交和外部化。

下图描述了 MySQL 组复制协议，并通过将其与 MySQL 复制（甚至 MySQL 半同步复制）进行比较，您可以看到一些差异。为了清晰起见，此图中缺少一些底层共识和 Paxos 相关消息。

图 20.3 MySQL 组复制协议