组复制是一种可用于实现容错系统的技术。复制组是一组服务器，每个服务器都有自己的完整数据副本（无共享复制方案），并通过消息传递相互交互。通信层提供了一组保证，例如原子消息和全序消息传递。这些都是非常强大的属性，可以转化为非常有用的抽象，人们可以利用这些抽象来构建更高级的数据库复制解决方案。
MySQL 组复制构建在此类属性和抽象之上，并实现了多源更新随处复制协议。复制组由多个服务器组成，组中的每个服务器可以随时独立执行事务。但是，所有读写事务只有在获得组批准后才会提交。换句话说，对于任何读写事务，组都需要决定是否提交，因此提交操作不是原始服务器单方面决定的。只读事务无需组内协调，立即提交。
当读写事务准备在原始服务器上提交时，服务器会自动广播写入值（已更改的行）和相应的写入集（已更新的行的唯一标识符）。由于事务是通过原子广播发送的，因此组中的所有服务器要么都接收到该事务，要么没有。如果他们收到它，那么他们都会以与之前发送的其他交易相同的顺序接收它。因此，所有服务器以相同的顺序接收相同的交易集合，并且为交易建立全局总顺序。
然而，在不同服务器上同时执行的事务之间可能存在冲突。通过在称为认证的过程中检查和比较两个不同并发事务的写入集来检测此类冲突 。在认证过程中，冲突检测是在行级别进行的：如果在不同服务器上执行的两个并发事务更新同一行，则存在冲突。冲突解决过程规定，首先排序的事务在所有服务器上提交，然后排序的事务第二次中止，因此在原始服务器上回滚并被组中的其他服务器删除。例如，如果 t1 和 t2 在不同站点同时执行，都更改同一行，并且 t2 在 t1 之前排序，则 t2 赢得冲突，并且 t1 被回滚。这实际上是分布式首次提交获胜规则。请注意，如果两个事务必然会经常发生冲突，那么最好在同一台服务器上启动它们，这样它们就有机会在本地锁管理器上同步，而不是由于认证而回滚。
为了应用和外部化经过认证的事务，组复制允许服务器偏离商定的事务顺序，前提是这不会破坏一致性和有效性。组复制是一种最终一致性系统，这意味着一旦传入流量减慢或停止，所有组成员都具有相同的数据内容。当流量流动时，交易可以以稍微不同的顺序外部化，或者在其他成员之前外部化到某些成员。例如，在多主模式中，本地事务可能会在认证后立即外部化，尽管全局顺序中较早的远程事务尚未应用。当认证过程确定交易之间不存在冲突时，这是允许的。在单主模式下，在主服务器上，并发的、不冲突的本地事务极有可能以与组复制商定的全局顺序不同的顺序提交和外部化。在不接受客户端写入的辅助节点上，事务始终按照商定的顺序提交和外部化。
下图描述了MySQL组复制协议，通过将其与MySQL复制（甚至MySQL半同步复制）进行比较，您可以看到一些差异。为了清楚起见，这张图中缺少一些潜在的共识和 Paxos 相关消息。
MySQL 组复制协议
源 1 收到的交易被执行。 然后，源 1 向由其自身、源 2 和源 3 组成的复制组发送一条消息。当所有三个成员达成共识时，它们将验证该事务。 然后，源 1 将事务写入其二进制日志，提交事务，并向客户端应用程序发送响应。 源 2 和 3 将事务写入其中继日志，然后应用它，将其写入二进制日志，然后提交。
