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