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