レプリケーションラグの修正
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
時刻 Tに、レプリカセットABCの指定されたセカンダリに適用された最後の書込み操作が、プライマリに適用された最新の操作より遅れていました。
アラート条件
プロジェクト レベルのアラート設定ページでアラート条件を構成して、trigger アラートを起動できます。
アラート条件の詳細については、「レプリケーション ラグは 」を参照してください。
一般的な Triggers
アイドル状態のレプリカセット。 報告されるレプリケーションラグは、実際には最後の書込み (write) 以降の時間だけです。 レプリケーションラグは、プライマリ の最後のoptimeとセカンダリが最後に受信した操作の時刻の間で計算されます。 レプリカセットが 10 分ごとにのみ書き込まれる場合、レプリケーションラグは、プライマリに書き込みが行われた後、次の書き込みがセカンダリに複製される直前に 10 分になります。
セカンダリ のプロビジョニングが不足しているため、より多くの割り当てリソースが必要であり、プライマリに追いつくことができません（読み取りスケーリングにセカンダリを使用する場合は一般的）。
プライマリとセカンダリ間で帯域幅が不足しているか、その他のネットワーク問題が発生しています。
当面の問題の修正
このアラートは、レプリケーションの遅延が 2 分以上続く場合にのみtriggerされるように、 の設定を調整します。 これにより、誤検知の可能性が減ります。
プライマリとセカンダリ間のネットワークの問題を解決します。
詳細については、MongoDB マニュアルの「 レプリカセットのトラブルシューティング 」を参照してください。
長期的な解決策の実装
プライマリとセカンダリ間の帯域幅を増やします。
セカンダリを、現在のプライマリとまったく同じ（またはそれ以上）プロビジョニングされたマシンに移動（またはアップグレード）します。
進捗状況の監視
進捗状況を監視するには、次のチャートを表示します。
Network
ネットワークのパフォーマンスを追跡するために、ネットワーク メトリクスを監視します。
Replication Headroom
レプリケーションのヘッドルームを監視して、セカンダリが oplog から削除される可能性があるかどうかを判断します。
Replication Lag
レプリケーション ラグを監視して、セカンダリが oplog から削除される可能性があるかどうかを判断します。
詳細については、 「 配置メトリクスの表示 」を参照してください。