快速修复方案：1. 检查组复制网络连通性，使用ping和telnet测试成员间端口3306连通；2. 重启mysqld服务或执行STOP GROUP_REPLICATION，然后START GROUP_REPLICATION；3. 设置group_replication_recovery_retry_count = 10并重试；4. 查看error log定位具体stats发送失败原因，如"Failed to send stats to member"，针对性清理网络或证书问题；5. 远程处理：通过SSH登录主节点，执行SET GLOBAL group_replication_group_name='uuid-new'重新注入成员。

错误原因详解

ER_GRP_RPL_SEND_STATS_ERROR通常发生在MySQL Group Replication中，成员尝试向组内其他成员发送统计信息时失败。常见触发场景：网络分区导致stats数据包丢失、防火墙阻挡组复制专用端口、成员证书过期或组成员状态异常（如RECOVERING卡住）。

从日志排查步骤

登录MySQL，执行SHOW REPLICA STATUS grs;查看Group Replication状态，关注Last_Error信息。如果看到ER_GRP_RPL_SEND_STATS_ERROR，检查/var/log/mysql/error.log中关键词"send_stats"，日志示例：2023-10-01 12:34:56 [ERROR] Plugin group_replication reported: 'Failed to send stats to x.x.x.x:33061'。然后用netstat -tlnp|grep 3306确认端口监听。

远程无侵入式修复

无需重启数据库，远程执行：ALTER INSTANCE RELOAD; 刷新实例配置；UPDATE performance_schema.replication_group_members SET member_role='SECONDARY' WHERE member_id='问题成员UUID'；等待组自动恢复。若无效，隔离问题节点：SET GLOBAL group_replication_exit_state_action=READ_ONLY;然后重启。

预防配置优化

在my.cnf添加：group_replication_recovery_complete_timeout=60; group_replication_unreachable_majority_timeout=30; group_replication_poll_spin_loops=10000; 这些参数增强网络抖动下的容错，重启生效后测试模拟网络延迟验证。

案例还原：生产环境处理

某集群3节点，主节点突然报ER_GRP_RPL_SEND_STATS_ERROR，日志显示发送到从节点192.168.1.3失败。排查发现从节点防火墙规则遗漏33061端口，执行firewall-cmd --add-port=33061/tcp --permanent; firewall-cmd --reload; 立即恢复正常，整个过程5分钟内完成，无数据丢失。

高级故障场景

如果错误伴随"certification failure"，检查gtid_executed表一致性：SELECT @@GLOBAL.GTID_EXECUTED; 跨节点对比。若不一致，执行RESET MASTER on问题节点后重新JOIN。证书问题用openssl verify检查，替换过期ca.pem。

FAQ
Q: ER_GRP_RPL_SEND_STATS_ERROR会导致数据丢失吗？
A: 不会，这是stats上报失败，核心复制事务不受影响。
Q: 如何快速确认是哪个成员导致的？
A: SHOW REPLICA STATUS grs; 查看Channels=group_replication_recovery Last_Error列。
Q: 修复后需要手动同步数据吗？
A: 不需要，Group Replication自动处理GTID一致性。
Q: 单节点环境会报这个错吗？
A: 不会，此错误仅多成员组复制场景出现。