oplog問題の修正
レプリケーション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 のサイズを変更するのに十分なスペースを確保するために、クラスターのストレージを増やす必要がある場合があります。
すべての書き込み操作で
majorityの 書込み保証（ write concern ） が指定されていることを確認し、次の書込み操作に進む前に書込みが少なくとも 1 つのノードに複製されることを確認します。 これにより、セカンダリが処理できるよりも速くプライマリが書き込みを受け入れるのを防ぐことで、アプリケーションからのトラフィックの速度を制御します。
長期的な解決策の実装
ユースケースの oplog のサイズ設定要件の詳細については、「 より大きなoplogサイズを必要とする可能性のあるワークロード 」を参照してください。
進捗状況の監視
これらのアラートが をtriggerすると、次のシナリオが観察されます。
メトリクス ビューのOplog GB / Hourグラフが上昇します。
メトリクス ビューのReplication Oplog Windowグラフは低くなっています。
セカンダリ ノードまたは非正常なノードの Atlas 表示および MongoDB ログのダウンロード には、次のメッセージが表示されます。
We are too stale to use <node>:27017 as a sync source. Atlas ノードがSTARTUP 2とRECOVERINGの状態を長時間報告しています。
通常、これはノードが「oplog から削除」され、プライマリ ノードによって生成される oplog データに追いつけないことを示します。 この場合、ノードによりデータが回復し、すべてのノード間でデータの一貫性が確保されるようにするために最初の同期が必要になります。
rs.status()shell メソッドを使用してノードの状態を確認できます。