MongoDB 複製：進入維護模式，10333 個其他維護模式任務正在進行中
我有一個需要重新同步的 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，但您也可以手動呼叫它。這是一組帶註釋的日誌行和相關的
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 transitioning from too-stale to valid sync source。