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

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

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

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

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

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

图 20.3 MySQL 组复制协议