レプリケーション Oplog アラートは、プライマリクラスター メンバーで生成されたoplog データの量が、クラスターに設定された oplog サイズを超えた場合にトリガーできます。
アラート条件
プロジェクト レベルのアラート設定ページで次のアラート条件を構成して、trigger アラートを起動できます。
Replication Oplog Window is (X) は、プライマリ レプリケーション oplog で使用可能なおおよその時間量が指定されたしきい値を満たすか、それを下回る場合に発生します。 これは、oplog データが生成される現在のレートでプライマリがログを継続できる時間を指します。
Oplog Data Per Hour is (X) プライマリ のレプリケーション oplog に書き込まれる 1 時間あたりのデータ量が、指定されたしきい値を満たすか超える場合に発生します。
一般的な Triggers
以下は、oplog アクティビティの増加につながる一般的なイベントです。
短期間で集中的に書込み (write) およびアップデート操作が行われます。
クラスターに構成された oplog サイズは、クラスターメトリクス ビューで確認されるOplog GB / Hourグラフの値より小さいです。
当面の問題の修正
レプリケーションoplogアラートを解決するために、以下を検討できるアクションをいくつか示します。
クラスターの構成を編集 して oplog サイズを増やし、クラスターOplog GB / Hour メトリクス ビュー の グラフの ピーク 値よりも高くなるようにします。
短期間に集中的な書込み (write) 操作とアップデート操作が発生することが予想され、oplog サイズを増やしてください。
注意
oplog のサイズを変更するのに十分なスペースを確保するために、クラスターのストレージを増やす必要がある場合があります。
すべての書き込み操作で の書込み保証（書込み保証 (write concern)が指定されていることを確認し、次の書込み操作に進む前に書込みが少なくとも
majority1 つのノードに複製されることを確認します。これにより、セカンダリが処理できるよりも速くプライマリが書き込みを受け入れるのを防ぐことで、アプリケーションからのトラフィックの速度を制御します。
長期的な解決策の実装
ユースユースケースの のサイズ設定要件の詳細については、「 より大きな Oplog サイズを必要とする可能性のあるワークロード oplog」を参照してください。
進捗状況の監視
これらのアラートが をtriggerすると、次のシナリオが観察されます。
メトリクス ビューのOplog GB / Hourグラフが上昇します。
メトリクス ビューのReplication Oplog Windowグラフは低くなっています。
セカンダリ ノードまたは非正常なノードの Atlas 表示およびMongoDBログのダウンロード には、次のメッセージが表示されます。
We are too stale to use <node>:27017 as a sync source. Atlasノードが、STARTUP2 と RECOVERING の状態が長期間にわたって報告されています。
通常、これはノードが "oplog" から削除されたことを示します。と は、 プライマリノードによって生成されるoplogデータに追いつけません。この場合、ノードデータが回復し、すべてのノード間でデータの一貫性が確保されるようにするために最初の同期 が必要になります。
rs.status()シェルメソッドを使用してノードの状態を確認できます。