失われたプライマリの修正
時刻 Tに、レプリカセットABCでプライマリは検出されませんでした。
アラート条件
プロジェクト レベルのアラート設定ページでアラート条件を構成して、trigger アラートをトリガーできます。
アラート条件の詳細については、「レプリカセットにはプライマリがない 」を参照してください。
一般的な Triggers
ネットワーク パーティションにより、レプリカセットのすべてのノードが相互に通信できなくなります。
レプリカセット内にプライマリを保持するための十分な投票ノードがありません。 プライマリが存在するには単純過半数が必要です。 これは、レプリカセットのハートビートに多くのホストがダウンしている（または応答していない）場合に発生する可能性があります。
プライマリがダウンすると、選出可能なノードはなくなります。
当面の問題の修正
レプリカセットで過半数の投票が利用可能であることを確認します。 ホストが永続的にシャットダウンされている場合は、レプリカセット構成からそれらが削除されていることを確認してください。
あるホストから別のホストへの基本的な ping テストを使用して、相互に通信できることを確認します。
長期的な解決策の実装
優先順位が 0 より大きいデータを保持するノードが複数あることを確認します。
詳細については、MongoDB マニュアルの 「レプリカ セットの選挙」 を参照してください。
進捗状況の監視
次のチャートを表示して、配置がリソースを消費するかどうかを監視します。
Normalized System CPU
CPU 使用率を監視して、データがメモリではなくディスクから取得されているかどうかを判断します。
Disk IOPs
ディスク IOPS が最大プロビジョニングされた IOPS に近づくかどうかを監視します。 配置が将来のワークロードを処理できるかどうかを判断してください。
Connections
接続を監視して、現在の接続制限が十分であるかどうかを判断
詳細については、 「 配置メトリクスの表示 」を参照してください。