复制技术

在详细介绍MySQL组复制之前，本节介绍一些背景概念以及工作原理的概述。这提供了一些上下文来帮助理解组复制所需的内容以及经典异步MySQL复制和组复制之间的区别。

主次复制

传统的MySQL复制提供了一种简单的主次复制方法。有一个主服务器（主服务器），有一个或多个辅助服务器（从服务器）。主数据库执行事务，将其提交，然后稍后（因此异步）将它们发送到第二数据库，以重新执行（在基于语句的复制中）或应用（在基于行的复制中）。这是一个无共享系统，默认情况下所有服务器都具有数据的完整副本。

MySQL异步复制

还有半同步复制，它向协议添加了一个同步步骤。这意味着主服务器在提交时等待辅助服务器确认已接收到事务。只有这样，主服务器才会恢复提交操作。

MySQL半同步复制

在上面的两张图片中，您可以看到经典的异步MySQL复制协议（及其半同步变体）的示意图。对角箭头表示服务器之间交换的消息或服务器与客户端应用程序之间交换的

组复制

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

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

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

但是，在不同服务器上同时执行的事务之间可能存在冲突。通过检查和比较两个不同并发事务的写集，可以在称为认证的过程中检测到此类冲突。在认证过程中，冲突检测是在行级别进行的：如果在不同服务器上执行的两个并发事务更新同一行，则存在冲突。冲突解决过程指出，已首先订购的事务在所有服务器上提交，而已订购第二的事务中止，因此在原始服务器上回滚并由组中的其他服务器丢弃。例如，如果t1和t2在不同的站点上同时执行，并且都更改了同一行，并且t2在t1之前排序，则t2赢得了冲突，并且t1被回滚。这实际上是一个分布式的首次提交胜出规则。请注意，如果两个处理必然会发生冲突，

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

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

MySQL组复制协议