MySQL Router从节点宕机后仍转发请求致失败，求优化处理方案

我来给你几个实用的解决思路，都是在生产环境里验证过的，能帮你缩短MySQL Router感知从节点宕机的时间，减少读请求失败的情况：

1. 强化路由节点的主动健康检查配置 #

你当前的元数据缓存TTL已经设为1秒，这是个不错的基础，但MySQL Router默认的节点健康检查机制偏被动。可以给每个路由段添加主动健康检查参数，让Router主动探测节点状态：

在你的各个[routing:*]配置段中加入以下参数：

health_check_interval=1      # 每秒检查一次节点状态
health_check_timeout=1       # 检查超时时间1秒
health_check_failure_threshold=2  # 连续2次失败就标记节点不可用

这样Router能在2秒内快速识别宕机节点，不再把请求转发过去。

2. 优化只读路由的故障转移策略 #

对于只读流量的路由段（比如magentoCluster_default_ro），可以修改路由策略为带故障转移的轮询模式，让Router在请求失败时立刻切换到其他可用节点，不用等元数据更新：

修改只读路由段的配置：

[routing:magentoCluster_default_ro]
# 保留原有参数，新增以下行
strategy=round-robin-with-failover

这个策略会在单个节点请求失败时，自动重试下一个可用节点，大幅降低请求失败的概率。

3. 缩短InnoDB集群的节点驱逐超时时间 #

MySQL Router的元数据来自InnoDB集群本身，所以集群对故障节点的标记速度直接影响Router的感知。默认的group_replication_member_expel_timeout是30秒，可以把它调小，让集群更快将宕机节点从成员列表中移除：

登录到集群的主节点执行：

SET GLOBAL group_replication_member_expel_timeout=2;
# 如果需要永久生效，写入my.cnf配置文件

这样集群会在2秒内把无响应的节点标记为不可用，Router获取的元数据也会同步更新。

4. 考虑升级MySQL Router版本 #

你当前使用的2.1.4版本比较老旧，后续的MySQL Router版本（比如8.0系列）在故障感知、元数据同步和健康检查机制上做了大量优化，比如更高效的增量元数据更新、更灵敏的节点探测逻辑。如果业务允许，升级到最新稳定版能从根本上改善这个问题。

注意事项 #

• 修改配置后需要重启MySQL Router才能生效；
• 健康检查间隔不要设置得过小（比如小于1秒），否则会给Router和集群节点带来额外负载，要根据业务压力平衡调整。

内容的提问来源于stack exchange，提问作者Sujan Kumar Sakthi