17.1.1.2 组复制

组复制是一种可用于实施容错系统的技术。复制组是一组服务器，每个服务器都有自己的完整数据副本(无共享复制方案)，并通过消息传递相互交互。通信层提供了一组保证，例如原子消息和总订单消息传递。这些功能非常强大，可以转化为非常有用的抽象，可以用来构建更高级的数据库复制解决方案。

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

当读写事务准备好在原始服务器上提交时，服务器自动 Broadcast 写值(已更改的行)和相应的写集(已更新的行的唯一标识符)。由于事务是通过原子 Broadcast 发送的，因此该组中的所有服务器都将接收该事务，否则将不会。如果他们收到了，那么相对于之前发送的其他事务，他们都将以相同的 Sequences 接收到它。因此，所有服务器都以相同的 Sequences 接收相同的 Transaction 集，并且为 Transaction 构建了全局总订单。

但是，在不同服务器上同时执行的事务之间可能存在冲突。通过检查并比较两个不同的并发事务的写集，可以发现这种冲突，该过程称为* certification *。在认证过程中，冲突检测是在行级别进行的：如果在不同服务器上执行的两个并发事务更新同一行，则存在冲突。冲突解决过程指出，已首先 Order 的事务在所有服务器上提交，而已 Order 第二的事务中止，因此在原始服务器上回滚并由组中的其他服务器丢弃。例如，如果 t1 和 t2 在不同的站点上同时执行，都更改了同一行，并且 t2 在 t1 之前被排序，则 t2 赢得了冲突，并且 t1 被回滚。这实际上是一个分布式的首次提交胜出规则。请注意，如果两个事务之间的冲突经常发生，那么在同一个服务器上启动它们是一个好习惯，在那里，它们有机会在本地锁 Management 器上进行同步，而不必由于认证而回滚。

对于应用和外部化已认证的 Transaction，如果不破坏一致性和有效性，组复制允许服务器偏离 Transaction 的约定 Sequences。组复制是最终的一致性系统，这意味着一旦传入流量减慢或停止，所有组成员将具有相同的数据内容。当流量在流动时，事务可以按略有不同的 Sequences 进行外部化，或者在某些成员之前对其他成员进行外部化。例如，在多主要模式下，尽管尚未应用全局 Sequences 中较早的远程事务，但是本地事务可能在认证后立即被外部化。当证明过程确定 Transaction 之间没有冲突时，这是允许的。在单主模式下，在主服务器上，并发，无冲突的本地事务以与组复制所同意的全局 Sequences 不同的 Sequences 进行提交和外部化的可能性很小。在不接受来自 Client 端的写操作的辅助服务器上，事务始终按照约定的 Sequences 进行提交和外部化。

下图描述了 MySQL 组复制协议，通过将其与 MySQL 复制(甚至 MySQL 半同步复制)进行比较，您可以看到一些区别。请注意，为清楚起见，此图中缺少一些基本的共识和 Paxos 相关的消息。

图 17.3 MySQL 组复制协议