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