MongoがSTARTUP2で動かなくなっているのはなぜですか？
セカンダリがいくつかあるMongoレプリカセットがあります。セカンダリインスタンスをホストするボックスがクラッシュし、データベースが失われました。
セカンダリMongoインスタンスを再び開始したところ、STARTUP2で12時間以上止まっています。理にかなっていますか？ドキュメントは、RECOVERING状態に入る前に、Mongoが短期間STARTUP2にある必要があると述べています
STARTUP2とはどういう意味ですか？プライマリからデータベースをコピーしていますか？どうすれば確認できますか（MongoがLinuxで実行されている場合）。
エオインブラジルの答えは部分的に正しくありません。新しいNodeは長期間STARTUP2に存在する可能性があります。投稿されたリンクは次のように述べています：
レプリカセットの各メンバーは、mongodがそのメンバーの構成の読み込みを完了するとすぐにSTARTUP2状態になり、その時点でレプリカセットのアクティブメンバーになります。次にメンバーは、初期同期を実行するかどうかを決定します。メンバーが初期同期を開始した場合、すべてのデータがコピーされてすべてのインデックスが作成されるまで、メンバーはSTARTUP2のままです。その後、メンバーはRECOVERINGに移行します。
700 GBのコレクションを管理していますが、新しいノードを追加しても、STARTUP2状態は24時間を超えています。しかし、データベースが大きくなるかどうかを監視することで、何かが起こっているかどうかを確認できます。新しいノードのデータベースのサイズは、
show databases
または、データディレクトリを観察して、まだ成長しているかどうかを確認することもできます。 （Linuxでは、コマンドls、df、du、iotopなどを使用します...）
STARTUP2状態は、ノードが投票できないことを意味します。 MongoDプロセスが構成のロードを完了すると、RSのメンバーはこの状態になります。この状態では、メンバーは内部レプリケーション操作を処理するためのスレッドを作成しましたが、状態をリカバリからそれ以降セカンダリに変更する必要があります（ [状態とドキュメントの詳細]を参照） 。
ノードがこの状態になってからしばらく経つと、奇妙な動作が発生します。なぜログが滞っているのかを特定するためにログなしでこれを分析することはほとんど不可能です。 rs.status（）とdb.printSlaveReplicationInfo（）を実行すると、ノードのローカル画像の詳細が表示されます。
これを解決する通常のアプローチは、ノードをシャットダウンし、そのデータファイル（dbpath内のファイル）をワイプして、再起動することです。これにより、初期同期プロセスが再開され、SECONDARYに移行するはずです。再度STARTUP2でスタックした場合は、ログを調べて理由に関する詳細情報を収集する必要があります。さまざまな原因がありますが、不安定なネットワークやローカルリソースの競合が原因で発生する可能性があります。
注意すべき1つの点は、最初の同期が進行中の間、ノードはSTARTUP2に留まるため、同期されるデータの量によっては、かなりの時間（場合によっては数日）になる可能性があるということです。
考えられる原因の1つは、セカンダリが "---"と表示されていることです here 。
メンバーを再同期するときは、RSに大きな負荷がかかっていないことを確認してください。
STARTUP2状態は、十分なディスク領域が原因である可能性があります。さて、同期する場所がないので、@ STARTUP2状態にとどまることしかできません。