#### 18.5.4.5分布式恢复的工作原理

[](<>)[](<>)

当组复制的分布式恢复过程从二进制日志执行状态传输时，为了将加入成员与施主同步到特定时间点，加入成员和施主使用GTID（请参阅[第17.1.3节，“使用全局事务标识符的复制”](replication-gtids.html))。然而，GTID仅提供一种方法来了解加入成员缺少哪些交易。它们不会帮助标记加入组的服务器必须赶上的特定时间点，也不会传递认证信息。这是二进制日志视图标记的工作，它标记二进制日志流中的视图更改，还包含额外的元数据信息，为加入成员提供缺少的认证相关数据。

本主题介绍视图更改和视图更改标识符的作用，以及从二进制日志执行状态传输的步骤。

##### 视图和视图更改

A.*看法*对应于在特定时间点积极参与当前配置的一组成员。他们在团队中正常运行并在线。

A.*视图更改*在对组配置进行修改时发生，例如成员加入或离开。任何组成员身份更改都会导致在同一逻辑时间点向所有成员传达独立的视图更改。

A.*视图标识符*唯一标识视图。每当视图发生更改时，都会生成它。

在组通信层，视图更改及其关联的视图标识符标记了成员加入前后交换的数据之间的边界。这个概念是通过二进制日志事件实现的：“查看更改日志事件”。记录视图标识符以区分在组成员身份发生更改之前和之后传输的事务。

视图标识符本身由两部分组成：随机生成的部分和单调递增的整数。随机生成的零件在创建组时生成，并且在组中至少有一个成员时保持不变。每次视图更改时，整数都会递增。使用这两个不同的部分，视图标识符可以识别由成员加入或离开导致的增量组更改，还可以识别所有成员在组完全关闭时离开组的情况，因此不保留组所在视图的任何信息。从一开始就启动组时，随机生成部分标识符可确保二进制日志中的数据标记保持唯一，并且在组完全关闭后不会重复使用相同的标识符，因为这将在将来导致分布式恢复问题。

##### 开始：稳定小组

所有服务器都处于联机状态，并处理来自该组的传入事务。有些服务器在复制事务方面可能有点落后，但最终会趋同。该组充当一个分布式复制数据库。

[](<>)

**图18.8稳定组**

<img alt="Servers S1, S2, and S3 are members of the group. The most recent item in all of their binary logs is transaction T20." src="images/gr-recovery-1.png" height="511" width="653" />

##### 查看更改：成员加入

每当有新成员加入组并因此执行视图更改时，每个在线服务器都会将视图更改日志事件排队等待执行。这是排队的，因为在视图更改之前，可以在服务器上排队等待应用多个事务，因此，这些事务属于旧视图。在它们之后排队视图更改事件可以保证正确标记发生这种情况的时间。

同时，加入会员通过视图抽象从会员服务提供的在线服务器列表中选择合适的捐赠者。成员加入视图 4，在线成员将视图更改事件写入二进制日志。

[](<>)

**图 18.9 成员加入**

<img alt="Server S4 joins the group and looks for a donor. Servers S1, S2, and S3 each queue the view change entry VC4 for their binary logs. Meanwhile, server S1 is receiving new transaction T21." src="images/gr-recovery-2.png" height="515" width="606" />

##### 状态转移：迎头赶上

如果组成员和加入成员是使用克隆插件设置的（请参阅[第 18.5.4.2 节，“用于分布式恢复的克隆”](group-replication-cloning.html))，并且加入成员和组之间的事务差异超过了为远程克隆操作设置的阈值 ([`group_replication_clone_threshold`](group-replication-options.html#sysvar_group_replication_clone_threshold))，Group Replication 通过远程克隆操作开始分布式恢复。如果任何组成员的二进制日志文件中不再存在所需的事务，也会执行远程克隆操作。在远程克隆操作期间，加入成员的现有数据将被删除，并替换为捐赠者数据的副本。当远程克隆操作完成并且加入的成员重新启动时，将执行来自捐赠者二进制日志的状态传输，以获取该组在远程克隆操作正在进行时应用的事务。如果没有大的事务间隙，或者如果没有安装克隆插件，组复制直接从捐赠者的二进制日志进行状态传输。

对于来自捐赠者二进制日志的状态转移，在加入成员和捐赠者之间建立连接，并开始状态转移。这种与捐助者的交互一直持续到加入组的应用程序线程的服务器处理视图更改日志事件，该事件对应于加入组的服务器进入组时触发的视图更改。换句话说，加入组的服务器从捐赠者那里复制，直到它到达具有与它已经在其中的视图标记匹配的视图标识符的标记。

[](<>)

**图 18.10 状态转移：迎头赶上**

<img alt="Server S4 has chosen server S2 as the donor. State transfer is executed from server S2 to server S4 until the view change entry VC4 is reached (view_id = VC4). Server S4 uses a temporary applier buffer for state transfer, and its binary log is currently empty." src="images/gr-recovery-3.png" height="524" width="620" />

由于视图标识符在同一逻辑时间传输给组中的所有成员，因此加入组的服务器知道它应该在哪个视图标识符处停止复制。这避免了复杂的 GTID 集计算，因为视图标识符清楚地标记了哪些数据属于每个组视图。

当加入组的服务器从捐赠者复制时，它也在缓存来自组的传入事务。最终，它停止从捐赠者复制并切换到应用缓存的那些。

[](<>)

**图 18.11 排队交易**

<img alt="State transfer is complete. Server S4 has applied the transactions up to T20 and written them to its binary log. Server S4 has cached transaction T21, which arrived after the view change, in a temporary applier buffer while recovering." src="images/gr-recovery-4.png" height="586" width="555" />

##### 完成：赶上

当加入组的服务器识别到具有预期视图标识符的视图更改日志事件时，与供体的连接将终止并开始应用缓存的事务。虽然它在二进制日志中充当标记，分隔视图更改，但视图更改日志事件也起着另一个作用。它传达了加入组的服务器进入组时所有服务器感知的认证信息，即最后一次视图更改。没有它，加入组的服务器将没有必要的信息来证明（检测冲突）后续事务。

追赶的持续时间不是确定性的，因为它取决于工作量和传入事务组的速率。这个过程是完全在线的，加入组的服务器在追赶时不会阻塞组中的任何其他服务器。因此，当服务器进入该阶段时，加入组的服务器落后的事务数量可能会有所不同，因此会根据工作负载而增加或减少。

当加入组的服务器达到零排队事务并且其存储的数据与其他成员相等时，其公共状态变为在线。

[](<>)

**图 18.12 在线实例**

<img alt="Server S4 is now an online member of the group. It has applied cached transaction T21, so its binary log shows the same items as the binary logs of the other group members, and it no longer needs the temporary applier buffer. New incoming transaction T22 is now received and applied by all group members." src="images/gr-recovery-5.png" height="510" width="652" />
