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 のサイズを変更するのに十分なスペースを確保するために、クラスターのストレージを増やす必要がある場合があります。

• Ensure that all write operations specify a write concern of majority to ensure that writes are replicated to at least one node before moving on to the next write operation. This controls the rate of traffic from your application by preventing the primary from accepting writes more quickly than the secondaries can handle.

  Atlas Infiniteクラスターでは、ストレージレイヤーがデータをレプリケートし、majorityはクラスターのノードの過半数ではなく、ストレージレイヤー内の過半数を指します。詳細を学ぶには、「Atlas Infiniteクラスターでの書込み保証 (write concern)」を参照してください。

長期的な解決策の実装

To learn about oplog sizing requirements for your use case, see Workloads that Might Require a Larger Oplog Size.

Atlas Infinite クラスターでは、oplog サイズを設定できません。Atlas がこれらのクラスターで oplog をどのように管理するかを学ぶには、「Atlas Infinite クラスターの oplog」を参照してください。

進捗状況の監視

これらのアラートが をtriggerすると、次のシナリオが観察されます。

• メトリクス ビューのOplog GB / Hourグラフが上昇します。

• メトリクス ビューのReplication Oplog Windowグラフは低くなっています。

• The Atlas View and Download MongoDB Logs of secondary or unhealthy nodes display the following message:

  We are too stale to use <node>:27017 as a sync source.

• An Atlas node is reporting a state of STARTUP2 and RECOVERING for an extended period of time.

  Typically, this indicates that the node has "fallen off the oplog" and is unable to keep up with the oplog data being generated by the primary node. In this case, the node will require an initial sync in order to recover and ensure that the data is consistent across all nodes. You can check the state of a node using the rs.status() shell method.