为什么Mongo卡在STARTUP2中？

我有一个Mongo副本集，其中包含一些辅助副本。承载辅助实例的盒子崩溃并丢失了数据库。

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

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

eoinbrazil的答案部分不正确。新节点可以在STARTUP2中使用很长时间。发布的链接显示：

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

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

show databases

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

STARTUP2状态意味着节点无法投票。一旦MongoD进程完成其配置的加载，RS的成员即会进入此状态。在此状态下，成员已创建线程来处理内部复制操作，但尚未将状态更改为Recovering，然后从该状态更改为Secondary（请参阅[状态及其详细信息，在docs]）。

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

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

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

一个可能的原因是，您的辅助变得“陈旧”的规定在这里。

当您重新同步成员时，请确保RS不在重负载下。

STARTUP2状态可能是由于磁盘空间不足所致。好吧，由于没有同步的地方，因此只能保持@ STARTUP2状态。