なぜMongoはSTARTUP2で動かなくなるのですか？

Mongoいくつかのセカンダリを含むレプリカセットがあります。セカンダリインスタンスをホストするボックスがクラッシュし、データベースが失われました。

セカンダリMongoインスタンスを再び起動しましたが、現在は12時間以上STARTUP2で停止しています。それは理にかなっていますか？ドキュメントはMongo、RECOVERING状態に入る前に、短時間STARTUP2にあるべきだと言っています

STARTUP2とはどういう意味ですか？プライマリからデータベースをコピーしていますか？どうすれば検証できますか（MongoがLinuxで実行されていると仮定）？

エオインブラジルの答えは部分的に間違っています。新しいノードは、STARTUP2に長時間存在する可能性があります。投稿されたリンクは言う：

レプリカセットの各メンバーは、mongodがそのメンバーの構成のロードを完了するとすぐにSTARTUP2状態に入り、その時点でレプリカセットのアクティブメンバーになります。その後、メンバーは最初の同期を行うかどうかを決定します。メンバーが最初の同期を開始すると、すべてのデータがコピーされ、すべてのインデックスが作成されるまで、メンバーはSTARTUP2に残ります。その後、メンバーはRECOVERINGに移行します。

700 GBのコレクションを管理しており、新しいノードを追加しても、STARTUP2の状態は24時間以上維持されます。ただし、データベースが成長するかどうかを監視することで、何かが起こっているかどうかを確認できます。新しいノードでデータベースのサイズを確認するには

show databases

または、データディレクトリを観察して、まだ成長しているかどうかを確認することもできます。（Linuxでは、コマンドls、df、du、iotopなどを使用して...）

STARTUP2状態は、ノードが投票できないことを意味します。RSのメンバーは、MongoDプロセスが構成の読み込みを完了すると、この状態に入ります。この状態では、メンバーは内部複製操作を処理するスレッドを作成しましたが、まだ状態をRecoveringに変更し、それ以降はセカンダリに変更していません（[状態とドキュメントの詳細]を参照）。

ノードが短期間以上この状態にある場合、奇妙な動作が発生しています。これは、ログなしで分析して、スタックしている理由を判別することはほとんど不可能です。rs.status（）およびdb.printSlaveReplicationInfo（）を実行すると、ノードのローカル画像に関する詳細が表示されます。

これを解決する通常の方法は、ノードをシャットダウンし、そのデータファイル（dbpath内のファイル）を消去してから再起動することです。これにより、最初の同期プロセスが再開され、SECONDARYに移行するはずです。STARTUP2で再びスタックする場合は、ログを調べて理由に関する詳細情報を収集する必要があります。さまざまな原因がありますが、発生する可能性があるのは不安定なネットワークまたはローカルリソースの競合です。

注意すべき1つの点は、最初の同期が進行している間、ノードはSTARTUP2のままになるため、同期されるデータの量によっては、かなりの時間（場合によっては数日）になる可能性があることです。

考えられる原因の1つは、ここで述べたように、セカンダリが「古くなった」ことです。

メンバーを再同期するときは、RSに大きな負荷がかかっていないことを確認してください。

STARTUP2状態は、十分なディスク容量がない可能性があります。さて、同期する場所がないため、@ STARTUP2状態しか維持できません。