MySQL 8.4 发行说明
当组复制的分布式恢复过程从二进制日志中执行状态转移以将加入的成员与捐赠者同步到特定时间点时，加入的成员和捐赠者会利用 GTID（请参阅 第 19.1.3 节，“使用全局事务标识符复制”）。但是，GTID 只能提供一种方式来识别加入的成员缺少哪些事务。它们不能帮助标记服务器加入组后必须赶上的特定时间点，也不能传达认证信息。这是二进制日志视图标记的工作，它们标记二进制日志流中的视图更改，并且还包含其他元数据信息，为加入的成员提供缺少的与认证相关的數據。
本主题解释了视图更改和视图更改标识符的作用，以及从二进制日志中执行状态转移的步骤。
一个 视图 对应于一组积极参与当前配置的成员，换句话说，在特定时间点。它们在组中正常运行且在线。
当对组配置进行修改时，例如成员加入或离开，就会发生 视图更改。任何组成员资格更改都会导致一个独立的视图更改，并在同一逻辑时间点传达给所有成员。
一个 视图标识符 唯一标识一个视图。它在发生视图更改时生成。
在组通信层，具有关联视图标识符的视图更改标记了成员加入之前和之后交换的数据之间的边界。该概念通过一个二进制日志事件实现：“视图更改日志事件”（VCLE）。视图标识符被记录下来，以区分在组成员资格发生变化之前和之后传输的事务。
视图标识符本身由两部分组成：一个随机生成的部分和一个单调递增的整数。随机生成的部分在创建组时生成，并在组中至少有一个成员时保持不变。每次发生视图更改时，整数都会递增。使用这两个不同的部分使视图标识符能够识别由于成员加入或离开而导致的增量组更改，并识别所有成员在完全组关闭时离开组的情况，因此不会保留关于组处于哪种视图的信息。在从头开始启动组时随机生成标识符的一部分，可以确保二进制日志中的数据标记保持唯一，并且在完全组关闭后不会重新使用相同的标识符，因为这会导致将来分布式恢复出现问题。
每当新的成员加入组，因此执行视图更改时，每个在线服务器都会排队执行视图更改日志事件。这是排队的，因为在视图更改之前，服务器上可能会排队几个要应用的事务，因此这些事务属于旧视图。在它们之后排队视图更改事件可以保证对更改发生时间的正确标记。
同时，加入的成员从成员服务通过视图抽象提供的在线服务器列表中选择合适的捐赠者。成员在视图 4 上加入，在线成员将视图更改事件写入二进制日志。
如果组成员和加入的成员都设置了克隆插件（请参阅 第 20.5.4.2 节，“用于分布式恢复的克隆”），并且加入的成员与组之间的事务差异超过了为远程克隆操作设置的阈值（group_replication_clone_threshold），组复制将使用远程克隆操作开始分布式恢复。如果所需的事务不再存在于任何组成员的二进制日志文件中，也会执行远程克隆操作。在远程克隆操作期间，加入的成员上的现有数据将被删除，并用捐赠者数据的副本替换。当远程克隆操作完成且加入的成员已重新启动后，将从捐赠者的二进制日志中执行状态转移，以获取在远程克隆操作进行期间组应用的事务。如果没有大的事务差距，或者没有安装克隆插件，组复制将直接进行从捐赠者的二进制日志中进行状态转移。
对于从捐赠者的二进制日志中进行状态转移，将在加入的成员和捐赠者之间建立连接，并开始状态转移。与捐赠者的这种交互将持续到加入组的服务器的应用程序线程处理对应于加入组的服务器进入组时触发的视图更改的视图更改日志事件为止。换句话说，加入组的服务器从捐赠者复制，直到它到达与它已经所在的视图标记匹配的视图标识符标记。
由于视图标识符是在同一逻辑时间传达给组中的所有成员的，因此加入组的服务器知道它应该在哪个视图标识符处停止复制。这避免了复杂的 GTID 集计算，因为视图标识符明确标记了哪些数据属于每个组视图。
当加入组的服务器从捐赠者处复制数据时，它也会缓存来自组的传入事务。最终，它会停止从捐赠者处复制，并切换到应用那些被缓存的事务。
当加入组的服务器识别到具有预期视图标识符的视图更改日志事件时，它会终止与捐赠者的连接并开始应用缓存的事务。尽管它在二进制日志中充当标记，界定视图更改，但视图更改日志事件也扮演着另一个角色。它传递了所有服务器在加入组的服务器进入组时感知的认证信息，换句话说，就是最后一次视图更改。如果没有它，加入组的服务器将没有必要的信息来认证（检测冲突）后续的事务。
追赶的持续时间是不确定的，因为它取决于工作负载和传入组的事务速率。此过程完全在线进行，加入组的服务器在追赶期间不会阻塞组中的任何其他服务器。因此，加入组的服务器在进入此阶段时落后的事务数量可能会因工作负载而异，因此会随着工作负载的增加或减少而增加或减少。
当加入组的服务器的队列事务数达到零，并且其存储的数据与其他成员相同，它的公共状态将变为在线。
