MySQL 8.4 Release Notes
20.5.4.5 分布式恢复工作原理
当 Group Replication 的分布式恢复过程在从二进制日志中进行状态转移，以将加入成员同步到捐赠者指定的时间点时，加入成员和捐赠者使用 GTIDs（见第19.1.3节，“基于全局事务标识符的复制”）。然而，GTIDs 只提供了了解加入成员缺少哪些事务的方式，而不是帮助标记服务器必须赶到的特定时间点，也不包含证书信息。这是二进制日志视图标记的工作，它们在二进制日志流中标记视图变化，并且包含额外的元数据信息，向加入成员提供缺少的证书相关数据。
本主题解释了视图变化和视图变化标识符的作用，以及从二进制日志进行状态转移的步骤。
一个视图对应于当前配置中参与活动的成员组，换言之，对于特定时间点。它们正在正确地在线工作在组中。
一个视图变化发生在组配置发生修改时，如成员加入或离开。任何组成员身份变化都将导致独立的视图变化，向所有成员传递相同的逻辑时间点。
一个视图标识符唯一标识一个视图。在视图变化发生时生成。
在群组通信层，视图变化及其关联的视图标识符标记了成员加入前后的数据交换边界。这一概念通过一个二进制日志事件实现：“视图变化日志事件”（VCLE）。视图标识符记录用于区分传输在成员加入之前和之后的交易。
视图标识符本身由两个部分组成：一个随机生成的部分和一个单调递增的整数。随机生成的部分是在群组创建时生成的，并且在至少有一个成员在群组中时保持不变。每当发生视图变化时，整数都会增加。使用这两个不同的部分使得视图标识符能够识别由成员加入或离开引起的增量群组变化，也能识别所有成员离开群组的情况，即全组shutdown，剩下的信息将是空的。从开始生成随机部分确保了二进制日志中的数据标记保持唯一，并且在全组shutdown后不会重新使用同样的标识符，因为这将导致未来分布式恢复中出现问题。
当新成员加入组并因此执行视图更改时，每个在线服务器都会排队一个视图更改日志事件以便执行。这是排队的原因，因为在视图更改之前，服务器上可能会有多个事务排队等待应用，并且这些事务属于旧视图。排队视图更改事件后它们可以正确地标记这个时间点。
与此同时，加入的成员通过视图抽象层由成员服务指定的在线服务器列表中选择合适的捐赠者。一个成员在视图4中加入，并且在线成员将视图更改事件写入到二进制日志中。
如果组成员和加入的成员都使用克隆插件（见第20.5.4.2节，“分布式恢复中的克隆”），并且加入的成员与组之间的事务差异超过远程克隆操作的阈值（group_ replication_clone_threshold），Group Replication 将开始分布式恢复过程中的远程克隆操作。远程克隆操作也将在任何组成员的二进制日志文件中不再存在所需事务时执行。在远程克隆操作期间，加入的成员上的现有数据将被删除，并用捐赠者的数据进行替换。当远程克隆操作完成后，加入的成员重启时，将从捐赠者的二进制日志中获取组在远程克隆操作进行时所应用的事务。如果没有大事务差异或克隆插件未安装，Group Replication 将直接转到从捐赠者的二进制日志中获取状态。
对于从捐赠者的二进制日志中获取状态，加入的成员和捐赠者之间将建立连接，然后开始状态传输。这与捐赠者之间的交互将继续，直到加入的成员的应用线程处理与加入的成员进入组时触发的视图变化日志事件。在其他字样，这意味着加入的成员从捐赠者中复制，直到它获取与自己当前在的视图标识符匹配的视图标识符。
在视图标识符传递给组中的所有成员时，加入组的服务器知道它应该停止复制的视图标识符。这避免了复杂的GTID集计算，因为视图标识符清楚地标记了每个组视图中的数据所属关系。
当服务器加入组时，它从捐赠者那里复制，同时也缓存来自组的 incoming事务。最终，它停止从捐赠者那里复制，并开始应用缓存的事务。
当服务器加入组识别期望的视图标识符的视图变化日志事件时，连接到捐赠者的终止，并开始应用缓存的事务。虽然它在二进制日志中作为一个标记，分隔视图变化，但视图变化日志事件也扮演着另一个角色。它传递了所有服务器在服务器加入组时所见证书信息，即最后一次视图变化。如果没有它，服务器加入组将无法检测冲突的事务。
事务的catch up时间不确定，因为它取决于工作负载和 incoming事务到组的速率。这整个过程是在线的，服务器加入组不会阻塞组中的其他服务器，因此当它移到这个阶段时，它可能落后的事务数量可以增加或减少，根据工作负载。
当服务器加入组达到零排队事务且其存储数据与其他成员相同时，其公共状态变为在线。
