ヘルスチェック ソリューション
項目一覧
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
このページでは、Cloud Manager のヘルスチェックによって発生する可能性のある問題とその解決策を提供します。
ホストの使用可能なディスク容量が減少している
Cloud Manager は、ディスクが 2 週間以下でいっぱいになると推定する場合、より多くのディスク容量が必要なホスト上のディスクと見なします。
この問題を解決するには、データベースをより容量のあるディスクに移動します。
ホストのディスク使用率が過剰
Cloud Manager では、ホスト上のディスクが長時間にわたってアクティブにデータを保存または取得している場合、ディスク使用率が過剰であると見なされます。
この問題を解決するには、データベースをよりスループットの高いディスクに移動します。
ホストには起動時の警告がある
起動時の警告を制限します
プロセスおよびユーザーの制限のデフォルト値が低いと、MongoDB の通常操作にさまざまな問題が発生させる可能性があります。 詳細と推奨事項については、MongoDB マニュアルのUNIX ulimit 設定を参照してください。
NUMA が有効な起動時の警告
NUMA を使用するシステムで MongoDB を実行すると、一定期間パフォーマンスが低下したり、システム プロセスの使用率が高くなったりするなど、さまざまな運用上の問題が発生する可能性があります。 詳細と推奨事項については、MongoDB マニュアルの「 MongoDB と NUMA ハードウェア」を参照してください。
Readahead
Readahead起動警告に関する情報と推奨事項については、MongoDB マニュアルのこのセクションの readahead 情報を参照してください。
THP（Transparent Huge Pages）+ デフラグ
Transparent Huge Pages and Defrag起動時の警告に関する情報と推奨事項については、「 Transparent Huge Page（THP）の無効化 」を参照してください。
ホストにアクセスできません
MongoDB Agent は、配置内の各 MongoDB プロセスに接続して診断データを収集します。
MongoDB Agent がプロセスに接続できない場合は、次の解決策を検討してください。
理由 | 解決法 |
|---|---|
ホストが存在しなくなりました。 | Cloud Manager からホストを削除します。 |
モニタリングはホストに到達できません。 | 可能な解決策については、「 ホストダウンアラートの解決策」を参照してください。 |
MongoDB のバージョンは古くなりました
Cloud Manager によって管理される MongoDB 配置では、Cloud Manager は配置の可用性を最大化すると同時に、MongoDB のリリース間で安全な自動アップグレードおよびダウングレード操作をサポートします。 Cloud Manager は、シャーディングされたクラスター、レプリカセット、スタンドアロンの MongoDB インスタンスのアップグレードおよびダウングレード操作をサポートしています。
「使用可能な MongoDB バージョンの設定」では、Cloud Manager で使用できる MongoDB のバージョンを選択する方法について説明します。
Cloud Manager が配置を管理しない場合は、MongoDB のバージョンを手動で変更します。 MongoDB マニュアルでは、各リリースでアップグレード チュートリアルを提供しています。 たとえば、以前のバージョンから MongoDB 4.2にアップグレードするには、「 MongoDB を4.2にアップグレードする 」を参照してください。
管理対象の配置の場合
MongoDB Cloud MongoDB Cloud ManagerManagerで、プロジェクトのGo {0 ページにGoします。Deployment
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processes ページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
詳細と注意事項については、「 MongoDB のバージョンの変更 」を参照してください。
レプリカセットの投票数は偶数
レプリカセット内の偶数の投票ノードでは、プライマリ ノードに障害が発生した場合に選挙の問題が発生する可能性があります。 奇数の投票数を確保するには、 レプリカセット に追加の投票ノードを追加することを検討する必要があります。
レプリカセットにアービタを追加すると、データを複製するノードのオーバーヘッドなしに、不均一な数のノードを許可できます。
配置が Cloud Manager によって管理されていない場合は、MongoDB マニュアルの手順に従って、レプリカセットにアービタを手動で追加します。
管理対象の配置の場合
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processes ページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
レプリカセットのデータを保持するノードは 3 つ未満
高可用性を確保するには、レプリカセットには少なくとも 3 つのデータを保持するノードを含めることをお勧めします。 高可用性に影響を与える要因については、MongoDB マニュアルの ページを参照してください。
配置が Cloud Manager によって管理されていない場合は、MongoDB マニュアルの手順に従って、レプリカセットにノードを手動で追加します。
管理対象の配置の場合
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processes ページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
レプリカセットにはバージョン ノードが混在しています
互換性がない可能性があるため、MongoDB インスタンスの古いバージョンからクラスターの最新バージョンにアップグレードすることをお勧めします。
配置が Cloud Manager によって管理されていない場合は、MongoDB のバージョンを手動で変更する必要があります。 MongoDB マニュアルでは、各リリースでアップグレード チュートリアルを提供しています。 たとえば、以前のバージョンから MongoDB 4.2にアップグレードするには、「 MongoDB を4.2にアップグレードする 」を参照してください。
管理対象の配置の場合
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processes ページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
詳細と注意事項については、「 MongoDB のバージョンの変更 」を参照してください。
レプリカセットには複数のアービタがある
予備選挙での投票権を追加するには、偶数のノードを含むレプリカセットにアービタを追加します。 アービタは常に 1 票だけを含むため、レプリカセットには不均一な数のノードを含めることができ、データを複製するノードのオーバーヘッドは発生しません。 選挙の同点を破棄するには、1 人のアービタのみが必要です。
配置が Cloud Manager によって管理されていない場合は、MongoDB マニュアルの手順に従って、レプリカセットからノードを手動で削除します。
管理対象の配置の場合
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processes ページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
配置アーキテクチャの詳細については、MongoDB マニュアルの「レプリカセット配置アーキテクチャ」を参照してください。
共有クラスターにはバージョン ノードが混在しています
シャーディングされたクラスターのコンポーネントは、さまざまなバージョンの MongoDB を実行します。
互換性の問題を回避するには、シャーディングされたクラスターを構成するすべてのmongos } プロセスとmongodプロセスに同じバージョンの MongoDB を使用します。 これには、クラスターのmongod コンフィギュレーションサーバー と シャード に使用されるすべての プロセスが含まれます。
mongodまたはmongosプロセスのバージョンを変更するには、「 MongoDB のバージョンの変更 」を参照してください。
キューに入れられた操作が多すぎる
キュー付き操作は、処理されるのを待機している操作です。 これは、ハードウェア容量に達した場合、またはクエリのパフォーマンスが低下している場合に発生することがあります。
Cloud Manager Premium へのアクセス権をお持ちの場合は、Cloud Manager プロファイラーを使用して長時間実行操作を追跡できます。 Cloud Manager でプロファイラー ツールを有効にするには、次の手順に従います。
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
Processes ページに移動します。
配置の [ Processes ] タブをクリックします。
[プロセス ]ページが表示されます。
Cloud Manager Premium にアクセスできない場合でも、パフォーマンスやデータベース操作に関する統計情報のためのプロファイリング データにアクセスできます。 データベースのプロファイリングの詳細については、「プロファイルデータベース 」を参照してください。
レプリケーションラグが多すぎる
レプリケーションラグは、プライマリでの操作と、oplog からセカンダリへのその操作の適用までの間の遅延です。 レプリケーションラグは重大な問題となり、MongoDB レプリカセット のデプロイに深刻な影響を与える可能性があります。 また、レプリケーションラグが長くなりすぎると、「遅延した」ノードはすぐにプライマリになる資格を失い、分散された読み取り操作が一貫性を失う可能性が高まります。
レプリケーションラグのトラブルシューティング方法については、MongoDB マニュアルの「 レプリケーション ラグの確認」を参照してください。