MySQL报错MY-013471，ER_GRP_RPL_RECOVERY_STRAT_CHOICE故障远程修复思路分享

这个MY-013471错误，根据MySQL官方手册的描述（来源：MySQL 8.0 Error Reference），就是MySQL组复制（Group Replication）在为一个新加入的成员选择数据恢复方式时出了问题，组复制的新成员需要从现有的集群成员那里获取一份最新的数据副本，这个过程叫做“恢复”，MySQL支持两种主要的恢复策略：一种叫克隆（Cloning），另一种叫增量恢复（Incremental Recovery）,也就是通过复制二进制日志来追数据。

这个错误的发生，意味着集群在自动或手动指定使用哪种恢复策略时，遇到了无法满足的条件，你可能配置了让新成员必须使用克隆方式来恢复，但集群里却没有一个成员开启了克隆插件；或者，系统自动选择策略时,发现两种策略都不可用。

当你在远程管理数据库，屏幕上跳出这个错误时，别慌，下面是一些可以按顺序尝试的排查和解决思路，所有操作最好在业务低峰期进行,并确保你有完整的备份。

第一步：立刻检查集群状态

你需要登录到集群中任意一个正常工作的成员节点上，查看整个集群的健康状况,执行命令：

SELECT * FROM performance_schema.replication_group_members;

你要重点关注几个信息：所有成员的MEMBER_STATE是不是都是ONLINE？新加入的那个成员的状态是不是RECOVERING并且卡住了？确认问题确实出在恢复阶段,这是后续操作的基础。

第二步：核查错误日志细节

这个MY-013471错误本身只是一个结果，真正的原因会记录在MySQL的错误日志文件中，你需要登录到那个无法正常加入集群的故障节点，去查看它的错误日志，日志的位置通常在MySQL的数据目录下，文件名一般是host_name.err。

用tail或cat命令查看日志末尾的最新内容，搜索“MY-013471”或者“ER_GRP_RPL_RECOVERY_STRAT_CHOICE”附近的信息，日志通常会给出更具体的说明，Cloning strategy required but no donor available with cloning enabled”（需要克隆策略但没有可用的开启了克隆功能的捐赠者）,这个具体信息是解决问题的关键线索。

第三步：根据日志提示，分情况处理

拿到错误日志的具体描述后，我们就可以有针对性地解决了,最常见的情况有以下两种：

情况A：要求克隆恢复，但无可用捐赠者

如果错误信息明确指出是克隆策略出了问题，比如找不到能提供克隆源的节点,那么你有两个选择：

1. 启用集群的克隆功能： 如果条件允许（磁盘空间充足，并且MySQL版本支持），这是在将来一劳永逸的办法，你需要在一个或多个现有的集群成员上安装克隆插件，在每个你希望作为克隆源（Donor）的节点上执行：

   

   INSTALL PLUGIN clone SONAME 'mysql_clone.so';

   安装完成后，再次尝试将新节点加入集群,系统应该就能自动找到可用的克隆源了。

2. 修改恢复策略设置： 如果你不想或暂时不能使用克隆功能，可以强制指定恢复策略为增量恢复，在故障节点上，先停止组复制（如果它还在尝试恢复的话）,然后设置全局变量：

   SET GLOBAL group_replication_recovery_retry_count = 10； -- 可以适当增加重试次数

   但更直接的是，确保没有强制要求使用克隆，检查一下全局变量group_replication_recovery_get_public_key（这个可能不直接相关）以及确认配置中没有硬性规定必须克隆，最根本的方法是在故障节点的配置文件（如my.cnf）中明确指定恢复方式,添加一行：

   group_replication_recovery_use_clone = OFF

   然后重启该节点的MySQL实例，再重新加入集群，这样,它就会尝试使用传统的增量恢复方式。

情况B：增量恢复策略失败

如果错误暗示增量恢复方式有问题，比如无法从捐赠者那里获取二进制日志,那么排查点在于：

1. 检查复制用户凭证： 确保你在group_replication_recovery通道下配置的复制用户（用户名和密码）在所有现有集群成员上都是正确且具有足够权限的，在捐赠者节点上，验证这个用户是否能正常登录并具有REPLICATION SLAVE等权限。

2. 检查网络连接和防火墙： 确保故障节点能正常访问集群中其他节点的复制端口（通常是3306和群组通信端口，如33061），远程修复时，防火墙规则是常见的“罪魁祸首”。

3. 检查二进制日志： 确认潜在的捐赠者节点没有丢失新节点所需要的二进制日志，如果新节点缺失的数据太旧，而老节点的二进制日志已经被清理了，那么增量恢复就会失败，这时，你可能不得不考虑使用克隆,或者从一个更近的全量备份中恢复该节点。

第四步：重启恢复过程

在进行了上述任何一项修正之后，通常需要重启故障节点的恢复过程，可以先执行STOP GROUP_REPLICATION;，然后再执行START GROUP_REPLICATION;，观察错误日志和replication_group_members表,看恢复是否能够顺利进行下去。

总结一下远程修复的核心思路：

先看集群大盘状态，确认问题范围；然后必看故障节点的详细错误日志，那是诊断的黄金标准；最后根据日志指明的具体原因，要么“补齐缺失的功能”（如开启克隆插件），要么“修正错误的配置”（如修改恢复策略或复制用户权限），整个过程需要你像侦探一样，根据日志这条关键线索，一步步缩小范围,最终解决问题。