我有一个需要重新同步的 MongoDB 实例。
2016-11-07T11:59:23.330+0000 I REPL [ReplicationExecutor] syncing from: x.x.x.x:27017
2016-11-07T11:59:23.354+0000 W REPL [rsBackgroundSync] we are too stale to use x.x.x.x:27017 as a sync source
2016-11-07T11:59:23.354+0000 I REPL [ReplicationExecutor] could not find member to sync from
2016-11-07T11:59:23.354+0000 E REPL [rsBackgroundSync] too stale to catch up -- entering maintenance mode
2016-11-07T11:59:23.354+0000 I REPL [rsBackgroundSync] our last optime : (term: 20, timestamp: Oct 4 07:41:29:1)
2016-11-07T11:59:23.354+0000 I REPL [rsBackgroundSync] oldest available is (term: 20, timestamp: Oct 17 02:13:33:5)
2016-11-07T11:59:23.354+0000 I REPL [rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember
2016-11-07T11:59:23.355+0000 I REPL [ReplicationExecutor] going into maintenance mode with 10333 other maintenance mode tasks in progress
这条线是什么意思?
[ReplicationExecutor] going into maintenance mode with 10333 other maintenance mode tasks in progress
什么是维护模式任务?没有来自 MongoDB 的文档。为什么有 10333 排队?如何查看它们(列表)?通过搜索引擎,我发现还记录条目with 0 other maintenance mode tasks in progress
“维护模式任务”消息是指对
replSetMaintenance
命令的连续调用的计数器,并且(在 MongoDB 3.4 中)与特定的排队任务无关。该replSetMaintenance
命令用于在完成一些维护工作时将辅助节点保持在 RECOVERING 状态。RECOVERING 成员保持在线并可能同步,但被排除在正常读取操作之外(例如,将辅助读取首选项与驱动程序一起使用)。每次调用replSetMaintenance
或者增加任务计数器(如果true
)或减少它(如果false
)。当计数器达到 0 时,成员将从 RECOVERING 转换回 SECONDARY 状态,假设它是健康的。在 MongoDB 3.4 中,维护模式的更改目前仅记录在 MongoDB 日志中。该命令一般只供 内部使用
mongod
,但您也可以手动调用它。这是一组带注释的日志行和相关的
mongo
shell 命令,显示了任务计数器的变化:在 MongoDB 3.2 中,一个变得“太陈旧”的副本集成员(即与副本集的另一个健康成员没有任何共同的 oplog 条目)将保持在 RECOVERING 模式并定期检查是否有新的有效同步源可用。当前每次检查都会增加“维护任务”计数器,因此如果成员已过时,这实际上并不表示任务的有意义数量。
从理论上讲,“太陈旧”并不是最终状态,因为可以想象,具有较大 oplog 的成员可能会暂时离线;在实践中,“太陈旧而无法赶上错误”通常意味着需要手动重新同步。
在这种情况下,有问题的副本集成员在两周前就失效了,因此维护模式计数器随着时间的推移继续攀升。MongoDB Jira 中有一个相关问题,您可以观看/投票:SERVER 23899: Reset maintenance mode when transition from too-stale to valid sync source。