主页 / dba / 问题 / 154464
Accepted
Sybil
Asked: 2016-11-08 04:24:55 +0800 CST

MongoDB 复制：进入维护模式，10333 个其他维护模式任务正在进行中

  • 772

我有一个需要重新同步的 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

maintenance mongodb

1 个回答

  1. Best Answer

    什么是维护模式任务？

    “维护模式任务”消息是指对replSetMaintenance命令的连续调用的计数器，并且（在 MongoDB 3.4 中）与特定的排队任务无关。该replSetMaintenance命令用于在完成一些维护工作时将辅助节点保持在 RECOVERING 状态。RECOVERING 成员保持在线并可能同步，但被排除在正常读取操作之外（例如，将辅助读取首选项与驱动程序一起使用）。每次调用replSetMaintenance或者增加任务计数器（如果true）或减少它（如果false）。当计数器达到 0 时，成员将从 RECOVERING 转换回 SECONDARY 状态，假设它是健康的。

    在 MongoDB 3.4 中，维护模式的更改目前仅记录在 MongoDB 日志中。该命令一般只供 内部使用mongod，但您也可以手动调用它。

    这是一组带注释的日志行和相关的mongoshell 命令，显示了任务计数器的变化：

    // db.adminCommand({replSetMaintenance: 1})
[ReplicationExecutor] going into maintenance mode with 0 other maintenance mode tasks in progress
[ReplicationExecutor] transition to RECOVERING

// db.adminCommand({replSetMaintenance: 1})
[ReplicationExecutor] going into maintenance mode with 1 other maintenance mode tasks in progress

// db.adminCommand({replSetMaintenance: 0})
[ReplicationExecutor] leaving maintenance mode (1 other maintenance mode tasks ongoing)

// db.adminCommand({replSetMaintenance: 0})
[ReplicationExecutor] leaving maintenance mode (0 other maintenance mode tasks ongoing)
[ReplicationExecutor] transition to SECONDARY

// db.adminCommand({replSetMaintenance: 0})
[ReplicationExecutor] Attempted to leave maintenance mode but it is not currently active

    为什么有 10333 排队？

    在 MongoDB 3.2 中，一个变得“太陈旧”的副本集成员（即与副本集的另一个健康成员没有任何共同的 oplog 条目）将保持在 RECOVERING 模式并定期检查是否有新的有效同步源可用。当前每次检查都会增加“维护任务”计数器，因此如果成员已过时，这实际上并不表示任务的有意义数量。

    从理论上讲，“太陈旧”并不是最终状态，因为可以想象，具有较大 oplog 的成员可能会暂时离线；在实践中，“太陈旧而无法赶上错误”通常意味着需要手动重新同步。

    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)

    在这种情况下，有问题的副本集成员在两周前就失效了，因此维护模式计数器随着时间的推移继续攀升。MongoDB Jira 中有一个相关问题，您可以观看/投票：SERVER 23899: Reset maintenance mode when transition from too-stale to valid sync source。

    • 4

相关问题