MongoDB 集群节点 RECOVERYING 状态解决办法

最新推荐文章于 2024-06-15 21:30:12 发布

weixin_42715413

最新推荐文章于 2024-06-15 21:30:12 发布

阅读量1.8k

点赞数

CC 4.0 BY-SA版权

文章标签： linux mongo recoverying

本文链接：https://blog.youkuaiyun.com/weixin_42715413/article/details/83271249

当MongoDB的shard节点进入RECOVERYING状态，可能因长时间未同步导致数据过旧。解决方法包括在低峰时段自动同步，如停止服务、清空数据文件后重启，或直接从其他正常节点复制数据文件。手动操作时要注意减少系统风险和数据丢失。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

mongo shard4节点状态：

2018-10-22T11:26:52.664+0800 I REPL     [replication-0] We are too stale to use 172.17.1.75:27013 as a sync source. Blacklisting this sync source because our last fetched timestamp: 5bc9d57a:40 is before their earliest timestamp: 5bcb3e7b:182c for 1min until: 2018-10-22T11:27:52.664+0800
2018-10-22T11:26:52.664+0800 I REPL     [replication-0] could not find member to sync from
2018-10-22T11:26:52.664+0800 E REPL     [rsBackgroundSync] too stale to catch up -- entering maintenance mode
2018-10-22T11:26:52.664+0800 I REPL     [rsBackgroundSync] Our newest OpTime : { ts: Timestamp 1539954042000|64, t: 8 }
2018-10-22T11:26:52.664+0800 I REPL     [rsBackgroundSync] Earliest OpTime available is { ts: Timestamp 1540046459000|6188, t: 53 }

本节点的最后时间戳比同步目标最早的时间戳还要早一分钟；也就是由于一些原因太久没有进行同步数据操作，而导致其他节点的数据操作日志已经覆盖，所以本节点被认为是太陈旧了，无法从其他节点同步数据。

解决：

主要一点记住，同步数据时候一定选在系统访问量最低的时间段进行。这样防止数据大量更新滞后，另一方面由于同步数据比较耗费资源的，降低系统down的风险。