MongoDBトラブルシューティングの5つの一般的なシナリオと迅速な修正

MongoDBのトラブルシューティングは、通常、アプリが遅くなったり、書き込みが失敗したり、レプリカセットが遅延したりしたときに始まります。このガイドでは、本番環境でよく見られる5つのシナリオを説明し、最初にどこを確認すべきかを示します。

これらのチェックを大きな変更を加える前の最初のパスとして使用してください。これらは、クエリの問題をインフラストラクチャ、レプリケーション、またはシャーディングの問題から分離するのに役立ちます。

1. 低速クエリパフォーマンス

低速クエリは、おそらく本番環境で報告される最も一般的なパフォーマンス問題です。ミリ秒ではなく秒単位でかかるクエリは、アプリケーションの応答性を著しく低下させる可能性があります。

診断：explain()の使用

低速クエリを診断する最初のステップは、なぜ遅いのかを理解することです。MongoDBのexplain()メソッドは、この分析に不可欠なツールです。実行計画を示し、どのインデックスが使用されたか（または使用されなかったか）を詳しく説明します。

コマンド例：

db.collection.find({ field: 'value' }).explain('executionStats')

出力を分析し、特に以下を確認します：

• winningPlan.stage：ステージがCOLLSCANの場合、MongoDBはすべてのドキュメントを読み取っています。これは、多くの場合、インデックスが欠落しているか使用できないことを示します。
• executionStats.nReturnedとexecutionStats.totalKeysExaminedおよびexecutionStats.totalDocsExaminedの比較。

迅速な修正

1. 適切なインデックスを作成する： クエリプランがコレクションスキャンを示している場合は、フィルターとソートパターンに一致するインデックスを追加します。たとえば、アプリがuser_idと最新のtimestampで注文を頻繁に検索する場合は、複合インデックスを作成します：

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. クエリを改善する： データを取得しすぎていないか確認します。プロジェクションを使用して、ページやジョブが実際に必要とするフィールドのみを返します。 3. 低速クエリログを確認する： ワークロードに適したしきい値でプロファイラーまたは低速クエリログを使用します。正確なしきい値は運用上の選択として扱い、普遍的なルールとして扱わないでください。

ヒント： インデックスは読み取り速度を向上させますが、書き込みをわずかに遅くします。クエリ述語（find()）、ソート操作（sort()）、または範囲クエリで頻繁に使用されるフィールドのみにインデックスを作成します。

2. レプリカセットのレプリケーションラグ

レプリケーションラグは、レプリカセットのセカンダリメンバーが、oplog（操作ログ）からの操作の適用においてプライマリメンバーに大幅に遅れをとるときに発生します。

診断：replSetGetStatusの確認

レプリカセットの任意のメンバーでreplSetGetStatusコマンドを使用して、すべてのメンバーの健全性と同期ステータスを確認します。

コマンド例：

rs.printReplicationInfo()
// またはステータスを直接クエリ：
rs.status()

プライマリとセカンダリのoptimeDateを確認します。プライマリのoptimeとセカンダリのoptimeの差がラグを示し、通常は各メンバーのsecsBehindフィールドに表示されます。

迅速な修正

1. ネットワークレイテンシを確認する： メンバー間の高レイテンシは、oplog転送を遅くする可能性があります。
2. 遅延しているセカンダリを確認する： 高いCPU、低速なディスクI/O、またはノイズの多い隣接ワークロードにより、セカンダリが書き込みを十分な速さで適用できなくなる可能性があります。
3. oplogカバレッジを確認する： ラグが深刻な場合、セカンダリに必要なoplogエントリが存在しなくなる可能性があります。その場合は、そのメンバーを再同期または再構築する必要があるかもしれません。

3. 接続エラーと認証失敗

アプリケーションサービスは、設定ミス、ファイアウォールの問題、または誤った認証情報が原因で、MongoDBへの接続に頻繁に失敗します。

診断：ログとネットワークの確認

まず、MongoDBサーバーが期待されるIPアドレスとポートでリッスンしていることを確認します。MongoDBサーバーログで特定のエラーを確認します。

一般的なログエラー：

• Address already in use：別のプロセスがポートを使用しています。
• Connection refused：サーバープロセスがダウンしているか、ブロックされているか、別の場所でリッスンしています。
• Authentication failed：ユーザー名、パスワード、認証データベース、またはロールの割り当てが間違っています。

迅速な修正

1. ファイアウォールルールを確認する： MongoDBポート（多くの場合27017）がアプリケーションホストから到達可能であることを確認します。
2. bindIpを確認する： mongod.confが127.0.0.1のみにバインドしている場合、リモートクライアントは接続できません。可能な場合は特定のプライベートインターフェースにバインドします。ネットワーク制御と認証がすでに整っていない限り、0.0.0.0は避けてください。
3. authSourceを確認する： ユーザーがadminで作成された場合、接続文字列に?authSource=adminが必要になる場合があります。

4. ディスク容量の不足

ドキュメントデータベースとして、MongoDBはデータを直接ディスクに保存します。予期しないデータ増加や不適切に処理されたデータベースクリーンアップは、すぐにディスク容量の枯渇につながり、すべての書き込み操作を停止させる可能性があります。

診断：モニタリングとdb.stats()

OSモニタリングツール（Linuxではdf -h）を使用して、全体的なディスク使用量を確認します。MongoDB内では、db.stats()コマンドを使用して、個々のデータベースが消費している容量を確認します。

コマンド例：

db.stats()

特にstorageSizeフィールドとdataSizeフィールドを確認します。

迅速な修正

1. 書き込みが失敗している場合の時間稼ぎ： 重要でないジョブを停止し、関連のない一時ファイルを削除するか、プラットフォームがサポートしている場合はボリュームを拡張します。
2. 未使用データを削除する： 古いコレクションやデータベースは、不要であることを確認し、バックアップが存在することを確認した後にのみ削除します。
3. 注意してコンパクト化する： 多くの削除や更新があるコレクションの場合、compactは予約済みスペースを解放する可能性がありますが、混乱を招く可能性があります。MongoDBのバージョンとストレージエンジンへの影響をテストします：

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. ストレージ容量を増やす： 長期的な修正は、通常、より大きなディスク、より良い保持ルール、またはログとバックアップ用の個別のストレージです。

警告： ディスクが完全にいっぱいになると、MongoDBはデータ破損を防ぐために書き込みを停止します。通常の操作を再開する前に、スペースの問題を解決する必要があります。

5. シャーディングクラスターエラー（古いルーター/コンフィグサーバー）

シャーディング環境では、コンフィグサーバー（config servers）またはクエリルーター（mongosインスタンス）内の接続または状態の問題により、システム全体が停止する可能性があります。

診断：クラスターの健全性の確認

mongosインスタンスに対して実行されるsh.status()コマンドは、シャーディングの健全性を診断するための主要なツールです。

実用的なコマンド例：

sh.status()

出力で確認すべき主な領域は次のとおりです：

• コンフィグサーバー： コンフィグサーバーレプリカセットに健全な過半数があることを確認します。
• シャード： リストされているすべてのシャードが接続され、正しく報告されていることを確認します。
• 古いステータス： ルーターまたはシャードに古いメタデータがあるという警告を探します。

迅速な修正

1. 必要に応じてmongosを再起動する： 1つのルーターが古くなっているか応答しない場合、再起動するとコンフィグサーバーへの新しい接続を強制できます。
2. 最初にコンフィグサーバーの健全性を修正する： コンフィグサーバーレプリカセットに健全な過半数がない場合、シャードメタデータ操作が失敗する可能性があります。
3. シャードレベルの問題を解決する： ディスク容量不足やレプリケーションラグが原因でシャードがダウンしている場合は、ルーターの症状を追跡する前に、その根本原因を修正します。

プロフェッショナルに相談するタイミング

データ損失の可能性がある場合、レプリカセットの再同期が必要な場合、コンフィグサーバーが正常でない場合、またはディスク容量がすでに書き込みに影響を与えている場合は、MongoDB管理者またはプラットフォームエンジニアを呼び出してください。本番環境でコンパクションやメンバーの再構築などの破壊的なコマンドを実行する前に、助けを求めてください。

まとめ

MongoDBのトラブルシューティングは、ユーザーへの影響に最も近い症状から始めます：遅いページ、接続失敗、書き込みの停止、遅延しているセカンダリ、またはシャーディングクラスターエラー。次に、explain()、rs.status()、db.stats()、sh.status()を使用して、インデックスの変更、ルーターの再起動、またはメンバーの再構築を行う前に原因を確認します。