#### 18.5.4.4 分布式恢复的容错

Group Replication 的分布式恢复过程具有许多内置措施，以确保在过程中出现任何问题时能够容错。

分布式恢复的捐助者是从当前视图中现有的合适在线组成员列表中随机选择的。选择随机捐助者意味着当多个成员进入组时，很有可能不会多次选择同一服务器。从 MySQL 8.0.17 开始，对于来自二进制日志的状态传输，joiner 仅选择与自身相比运行的 MySQL Server 的补丁版本较低或相等的捐赠者。对于早期版本，所有在线成员都可以成为捐赠者。对于远程克隆操作，加入者只选择与自己运行相同补丁版本的捐赠者。请注意，当加入成员在操作结束时重新启动时，它会与新的捐赠者建立连接以从二进制日志中传输状态，该捐赠者可能与用于远程克隆操作的原始捐赠者不同。

在以下情况下，Group Replication 检测到分布式恢复中的错误，自动切换到新的捐助者，并重试状态转移：

-   *连接错误*- 与候选捐赠者建立连接时存在身份验证问题或其他问题。

-   *复制错误*- 用于从二进制日志传输状态的复制线程之一（接收器或应用程序线程）失败。因为这种状态转移方法使用了现有的 MySQL 复制框架，所以一些瞬时错误可能会导致接收器或应用程序线程中的错误。

-   *远程克隆操作错误*- 远程克隆操作失败或在完成之前停止。

-   *捐赠者离开小组*- 捐助者离开组，或者捐助者上的组复制停止，而状态转移正在进行中。

    性能模式表[`replication_applier_status_by_worker`](performance-schema-replication-applier-status-by-worker-table.html)显示导致上次重试的错误。在这些情况下，将尝试与新的候选捐助者建立错误后的新连接。在发生错误时选择不同的捐赠者意味着新的候选捐赠者有可能没有相同的错误。如果安装了克隆插件，Group Replication 会首先尝试与每个合适的在线克隆支持捐赠者进行远程克隆操作。如果所有这些尝试都失败了，如果可能的话，组复制会依次尝试从二进制日志与所有合适的捐助者进行状态传输。

警告

对于远程克隆操作，在远程克隆操作开始从捐赠者传输数据之前，用户创建的表空间和接收者（加入成员）上的数据将被删除。如果远程克隆操作开始但未完成，则加入成员可能会留下部分原始数据文件集，或者没有用户数据。如果克隆操作在数据完全克隆之前停止，则捐赠者传输的数据将从接收者中删除。这种情况可以通过重试克隆操作来修复，组复制会自动执行该操作。

在以下情况下，分布式恢复过程无法完成，加入的成员离开组：

-   *清除交易*-加入成员所需的事务不存在于任何在线组成员的二进制日志文件中，并且无法通过远程克隆操作获取数据（因为未安装克隆插件，或者因为尝试与所有可能的捐赠者进行克隆但失败）。因此，加入的成员无法赶上团队。

-   *额外交易*-加入成员已包含组中不存在的某些事务。如果执行了远程克隆操作，这些事务将被删除并丢失，因为加入成员上的数据目录已被删除。如果从捐赠者的二进制日志进行状态转移，这些事务可能与该组的事务冲突。有关处理这种情况的建议，请参阅[额外交易](group-replication-gtids.html#group-replication-gtids-extra).

-   *已达到连接重试限制*-加入成员已进行连接重试限制允许的所有连接尝试。您可以使用[`组\u复制\u恢复\u重试\u计数`](group-replication-options.html#sysvar_group_replication_recovery_retry_count)系统变量（参见[第18.5.4.3节，“配置分布式恢复”](group-replication-tuning-recovery.html)).

-   *不再有捐赠者*-加入成员依次尝试与每个在线克隆支持捐赠者进行远程克隆操作失败（如果安装了克隆插件），然后依次尝试与每个合适的在线捐赠者从二进制日志进行状态传输失败（如果可能）。

-   *加入的成员离开小组*-加入成员离开组，或在状态转移过程中，在加入成员上停止组复制。

    如果加入成员无意中离开集团，则在除最后一个以外的任何上述情况下，该成员将继续采取集团规定的行动[`组\复制\退出\状态\操作`](group-replication-options.html#sysvar_group_replication_exit_state_action)系统变量。