Group Replication的分布式恢复过程内置了多项措施，确保在过程中出现任何问题时的容错性。
分布式恢复的捐赠者是从当前视图中现有的合适的在线组成员列表中随机选择的。选择随机捐赠者意味着当多个成员进入该组时，很有可能不会多次选择同一服务器。从 MySQL 8.0.17 开始，对于二进制日志的状态传输，加入者仅选择运行与自身相比更低或相等的 MySQL Server 补丁版本的捐赠者。对于较早的版本，所有在线成员都可以成为捐赠者。对于远程克隆操作，加入者只选择运行与自己相同补丁版本的捐赠者。请注意，当加入成员在操作结束时重新启动时，
在以下情况下，Group Replication 检测到分布式恢复错误，自动切换到新的捐赠者，并重试状态转移：
连接错误- 与候选捐赠者建立连接时存在身份验证问题或其他问题。
复制错误- 用于从二进制日志传输状态的复制线程之一（接收方或应用程序线程）失败。由于这种状态传输方法使用现有的 MySQL 复制框架，因此一些瞬态错误可能会导致接收方或应用程序线程出错。
远程克隆操作错误- 远程克隆操作失败或在完成之前停止。
Donor 离开组- Donor 离开组，或者组复制在 Donor 上停止，而状态转移正在进行中。
Performance Schema 表
replication_applier_status_by_worker
显示导致上次重试的错误。在这些情况下，将尝试与新的候选供体建立错误后的新连接。在出现错误的情况下选择不同的供体意味着新的候选供体有可能不会出现相同的错误。如果安装了克隆插件，Group Replication 会首先尝试与每个合适的在线克隆支持捐赠者进行远程克隆操作。如果所有这些尝试都失败了，如果可能的话，Group Replication 会依次尝试与所有合适的捐赠者从二进制日志进行状态传输。
对于远程克隆操作，在远程克隆操作开始从捐赠者传输数据之前，用户创建的表空间和接收者（加入成员）上的数据将被删除。如果远程克隆操作开始但未完成，加入的成员可能会留下其原始数据文件的一部分，或者没有用户数据。如果在完全克隆数据之前停止克隆操作，则捐赠者传输的数据将从接收者处删除。这种情况可以通过重试克隆操作来修复，Group Replication 会自动执行该操作。
在以下情况下，分布式恢复过程无法完成，加入成员离开群组：
Purged transactions - 加入成员需要的事务不存在于任何联机组成员的二进制日志文件中，并且无法通过远程克隆操作获取数据（因为没有安装克隆插件，或者因为尝试克隆所有可能的捐助者但失败了）。加入的成员因此无法赶上该组。
额外交易- 加入成员已经包含一些不存在于组中的交易。如果执行了远程克隆操作，这些事务将被删除和丢失，因为加入成员上的数据目录已被删除。如果从捐助者的二进制日志执行状态传输，这些交易可能会与该组的交易发生冲突。有关处理这种情况的建议，请参阅 额外交易。
已达到连接重试限制- 加入成员已进行连接重试限制允许的所有连接尝试。您可以使用
group_replication_recovery_retry_count系统变量对其进行配置（请参阅 第 18.5.4.3 节，“配置分布式恢复”）。没有更多的捐助者 - 加入成员依次尝试与每个支持在线克隆的捐助者进行远程克隆操作失败（如果安装了克隆插件），然后尝试从二进制日志与每个合适的在线捐助者进行状态传输失败如果可能的话，反过来捐助者。
加入成员离开组- 加入成员离开组，或者在状态转移正在进行时组复制在加入成员上停止。
如果加入的成员无意中离开了组，那么在上面列出的任何情况下，除了最后一种情况，它都会继续执行
group_replication_exit_state_action
系统变量指定的操作。