MongoDB 4.0.16分片集群均衡时出现Unable to establish remote cursors问题咨询

报错具体含义 #

该INFO级日志为MongoDB分片集群的正常元数据校验输出：均衡过程中prod.assests集合的chunk发生迁移后，mongos节点本地缓存的集合分片元数据版本，和分片节点上实际存储的最新版本不一致，导致查询请求尝试在分片节点建立远程游标时触发版本校验失败。
日志中vReceived是mongos节点持有的旧版本号Timestamp(1841827, 4)，vWanted是分片侧的当前有效版本号Timestamp(1841826, 1)，两者的Epoch值一致，说明属于同一个集合的正常版本迭代，不存在元数据损坏问题。
目前集群功能、业务访问、均衡流程均正常，说明mongos已经自动触发了元数据刷新，该报错不会对业务产生实际影响，无需重点关注。

报错触发原因及排查建议 #

触发原因 #

该报错仅出现在prod.assests集合均衡时，通常有以下几个原因：

• 该集合的总数据量、chunk数量远多于集群内其他集合，均衡过程中chunk迁移频率更高，mongos缓存的元数据过期概率更大
• 该集合的访问频率高于其他集合，刚好在chunk迁移的时间窗口有请求发送到已经迁出对应chunk的分片节点，触发校验失败
• MongoDB 4.0.16版本存在已知的元数据缓存刷新延迟优化不足的问题，大集合均衡场景下更容易输出这类日志

排查建议 #

• 执行db.getSiblingDB("prod").assests.getShardDistribution()，确认该集合的chunk数量，检查是否存在大量jumbo chunk（不可拆分的超大块），jumbo chunk会导致均衡过程中版本迭代更频繁
• 执行sh.status()查看该集合的分片键设计是否合理，是否存在热点分片导致该集合的迁移任务远多于其他集合
• 查询config.changelog集合，确认该集合的均衡迁移任务是否存在失败重试的情况，重复迁移会多次触发元数据版本变更

修复方案 #

• 仅出现该INFO日志、无业务报错、均衡流程正常的场景下，无需做任何处理，mongos会自动完成元数据缓存刷新，不影响集群运行
• 如果后续出现业务侧返回StaleConfig错误、或者均衡任务卡住，可按以下步骤处理：
  • 手动刷新所有mongos节点的全局元数据缓存：db.adminCommand({flushRouterConfig: 1})
  • 也可单独刷新该集合的元数据缓存：db.adminCommand({flushRouterConfig: "prod.assests"})
  • 如果存在大量jumbo chunk，可在业务低峰期手动拆分jumbo chunk，降低均衡过程的版本变更频率
• 长期优化可将集群升级到4.4及以上版本，该版本大幅优化了分片元数据同步逻辑，可显著减少这类日志的输出。

内容的提问来源于stack exchange，提问作者R2D2