#### 18.1.1.2组复制

[](<>)

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

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

当读写事务准备在原始服务器上提交时，服务器会自动广播写值（已更改的行）和相应的写集（已更新行的唯一标识符）。因为事务是通过原子广播发送的，所以组中的所有服务器要么接收事务，要么不接收。如果他们收到它，那么他们都会按照与之前发送的其他事务相同的顺序接收它。因此，所有服务器都以相同的顺序接收相同的事务集，并为这些事务建立全局总顺序。

但是，在不同服务器上并发执行的事务之间可能存在冲突。在一个名为*证明*.在认证期间，冲突检测在行级别执行：如果在不同服务器上执行的两个并发事务更新了同一行，则存在冲突。冲突解决过程声明，首先订购的事务在所有服务器上提交，然后订购的事务中止，因此在原始服务器上回滚，并由组中的其他服务器丢弃。例如，如果t1和t2在不同的站点同时执行，它们都更改了同一行，并且t2在t1之前排序，那么t2赢得冲突，t1回滚。事实上，这是一个分布式的首次提交赢家规则。请注意，如果两个事务经常会发生冲突，那么最好在同一台服务器上启动它们，这样它们就有机会在本地锁管理器上同步，而不是由于认证而回滚。

为了应用和外部化经认证的事务，如果不破坏一致性和有效性，组复制允许服务器偏离事务的约定顺序。组复制是一个最终的一致性系统，这意味着一旦传入流量减慢或停止，所有组成员都具有相同的数据内容。当流量流动时，事务可以以稍微不同的顺序外部化，或者先在某些成员身上外部化，然后再在其他成员身上外部化。例如，在多主模式下，本地事务可能会在认证后立即外部化，尽管尚未应用全局顺序中较早的远程事务。当认证流程确定交易之间没有冲突时，这是允许的。在单主模式下，在主服务器上，以与组复制商定的全局顺序不同的顺序提交和外部化并发、无冲突的本地事务的可能性很小。在不接受客户写入的二级数据库上，事务总是按照约定的顺序提交和外部化。

下图描述了MySQL组复制协议，通过将其与MySQL复制（甚至是MySQL半同步复制）进行比较，您可以看到一些差异。为了清晰起见，这幅图中缺少一些潜在的共识和与Paxos相关的信息。

[](<>)

**图18.3 MySQL组复制协议**

<img alt="A transaction received by Source 1 is executed. Source 1 then sends a message to the replication group, consisting of itself, Source 2, and Source 3. When all three members have reached consensus, they certify the transaction. Source 1 then writes the transaction to its binary log, commits it, and sends a response to the client application. Sources 2 and 3 write the transaction to their relay logs, then apply it, write it to the binary log, and commit it." src="images/gr-replication-diagram.png" height="328" width="725" />
