(EC2 に) 3 つのメンバーを持つ標準的な mongoDB レプリカ セットがあります。すべて正常に動作しますが、プライマリの CPU が 100 を超えることがあります。しかし、そうはなりません。
インスタンスをシャットダウンすると、選挙が正常に機能するため、ネットワーク経由でアクセスできない場合にのみ、mongo が異常と見なすと思います。
Cloudwatch を使用すると、CPU アラームがトリガーされたときにイベント (インスタンスの停止/再起動) を設定できますが、これは解決策というより回避策だと思います。
では、mongodb がメンバーを不健康と見なすのはいつですか?
少し複雑ですが、通常、レプリカ セットのメンバーがレプリカ セットのハートビートへの応答を停止すると、異常と見なされます。これらは 2 秒ごとに送信され、10 秒以内に応答が返されます (参照)。
ハートビートは意図的に軽量化されており、応答を作成するために大量のリソースを必要としないため、ビジー状態のシステムでも正常な状態を維持できます。
1 秒前に戻ると、CPU が 100 を超えていても、特に最新のマルチコア システムでは、必ずしも健全ではありません。一般に、遅いクエリやその他のパフォーマンスの低下が見られるかどうかによって、データベース インスタンスの正常性を測定することをお勧めします。必ず CPU のスパイクの原因を突き止め、対処/緩和を試みますが、一般的に、CPU 使用率はデータベース パフォーマンスの優れたバロメーターにはなりません (もちろん、すべてのコアが 100% で、データベースが最終的に停止しない限り)。 CPUが不足しています）。
最後に、MongoDB インスタンスをシャットダウンしたり、新しいプライマリが選択されるのを不健全にする必要はありません。代わりrs.stepDown()に、プライマリでコマンドを発行するだけです。選択に対して不適格とマークされ、新しいプライマリが選択されます。