私は現在、開発ボックスでジャーナリングを無効にしているため、replicaSet として 3 台のサーバーを備えた 64 ビット マシンで Mongodb 2.4.8 を使用しています。
耐久性はアプリケーションにとってそれほど重要ではないため、Journaling Option を無効にした理由です。
ジャーナリングの利点は 1 つだけだと思います。つまり、シャットダウンが正しくない場合、ジャーナリングが処理してくれるので、修復コマンドを発行する必要はありません。
この不潔なシャットダウンを生成するためkill -9に、Mongo プロセス ID を使用して mongo レプリカ プロセスを強制終了しました。mongo ロックを削除し、mongo プライマリ、セカンダリ、および任意のサーバーを再起動しました。すべてが正常に開始されました。
私の質問は、いつ実際に修復コマンドを発行する必要があるかということです（ロックの削除と再起動が機能するため）
生産中のジャーナリングを無効にするリスクを知りたかったので、質問がばかげている場合はご容赦ください。
repairDatabaseコマンドは、データベース全体で破損したデータをチェックし、そのデータを破棄して、残りのデータを再び使用できるようにします。
これは、不明確なシャットダウンの後に必要になる場合があります。あなたの場合、シャットダウンによってデータが破損しているようには見えませんでした（または、破損した可能性がありますが、問題のデータがまだアクセスされていないため、まだ明らかになりませんでした）。しかし、これが常に当てはまるというわけではありません。その瞬間、データベースは実際に何かをしていましたか? データベースがアイドル状態であるか、読み取り操作のみを実行している場合、通常、心配する必要はあまりありません。しかし、現在大規模な書き込み操作の最中に、ジャーナリングなしで突然シャットダウンすると、はるかに面倒になる可能性があります。
データベースが破損している可能性があり、repairDatabase が役立つ可能性がある別のシナリオは、ストレージ メディアの物理的な誤動作または基盤となるファイル システムの破損です。
レプリカ セットに関する重要な注意事項: レプリカセットがあり、1 つのノードのみが破損している場合は、そのノードを削除して、レプリカ セットの他のメンバーから再構築する必要があります。RepairDatabase は、破損したデータを破棄します。レプリカ セットからの復元はできません。