为什么 Mongo 卡在 STARTUP2 中？

Question

我有一个Mongo带有几个辅助节点的副本集。一个装有辅助实例的盒子崩溃并丢失了数据库。

我Mongo再次启动了辅助实例，现在它在 STARTUP2 中停留了 12 多个小时。是否有意义 ？文档说Mongo在进入 RECOVERING 状态之前应该在 STARTUP2 中停留一小段时间

STARTUP2 到底是什么意思？它是从主数据库复制数据库吗？我如何验证它（假设 Mongo 在 Linux 中运行）？

Answer 1

eoinbrazil 的答案部分不正确。一个新节点可以在 STARTUP2 中停留很长时间。发布的链接说：

mongod 完成加载该成员的配置后，副本集的每个成员都会进入 STARTUP2 状态，此时它成为副本集的活动成员。然后成员决定是否进行初始同步。如果成员开始初始同步，则该成员将保留在 STARTUP2 中，直到复制所有数据并构建所有索引。之后，成员过渡到 RECOVERING。

我正在管理一个 700 GB 的集合，当我添加一个新节点时，STARTUP2 状态会保持超过 24 小时。但是您仍然可以通过观察数据库是否增长来查看是否发生了某些事情。您可以使用以下命令查看新节点上的数据库大小

show databases

或者你也可以观察数据目录，看看它是否还在增长。（在 linux 上使用命令 ls、df、du、iotop 等......）

Answer 2

STARTUP2 状态表示“成员已加入集合并正在运行初始同步。有资格投票”。一旦 MongoD 进程完成加载其配置，RS 的成员就会进入此状态。在此状态下，成员已创建线程来处理内部复制操作，但尚未将状态更改为“正在恢复”，并从该状态更改为“辅助”（请参阅​​[文档中的状态及其详细信息]）。

如果您的节点处于这种状态的时间超过了很短的时间，那么您就会遇到一些奇怪的行为。如果没有日志来确定卡住的原因，几乎不可能进行分析。运行 rs.status() 和 db.printSlaveReplicationInfo() 将为您提供有关节点上本地图片的一些详细信息。

解决此问题的正常方法是关闭节点，擦除其数据文件（dbpath 中的那些文件），然后重新启动它。这将重新启动初始同步过程，并且应移至 SECONDARY。如果它再次卡在 STARTUP2 中，您需要查看日志以收集更多有关原因的信息 - 原因有多种，但可能发生的原因是网络不稳定或某些本地资源争用。

需要注意的一点是，当初始同步正在进行时，节点将保持在 STARTUP2 状态，因此根据同步的数据量，这可能需要相当长的时间（可能是几天）。