oplog関連のパラメーターの設定 - ApsaraDB for MongoDB - Alibaba Cloud ドキュメントセンター

ApsaraDB for MongoDBインスタンスにoplog関連のパラメーターを不適切に設定した場合、プライマリインスタンスとセカンダリインスタンスの間で異常な同期が発生し、レプリカセットインスタンスのデータを以前の時点に復元できません。このトピックでは、oplog関連のパラメーターを設定する方法と、不適切なoplog設定のリスクについて説明します。

Oplog概要

ApsaraDB for MongoDBレプリカセットインスタンスのプライマリ /セカンダリレプリケーションは、インスタンスの操作ログ (oplog) エントリによって実装されます。インスタンス内のlocal.oplog.rsという名前のoplogは、データベース内のすべてのドキュメントに対して実行された変更操作を格納する特別なキャップ付きコレクションです。 oplogは次の基本機能を提供します。

レプリカセットインスタンスでは、書き込み操作はインスタンスのプライマリノードでのみ完了し、対応するoplogエントリはノードで生成されます。インスタンス内の他のセカンダリノードは、oplogエントリを非同期的に複製し、エントリ自体を再生して、一貫したプライマリ /セカンダリレプリケーションを維持します。
操作がドキュメントを変更しないか失敗した場合、対応するoplogエントリは生成されません。
oplogエントリは、レプリカセットインスタンス内のすべてのノードで同一です。インスタンスのoplogのエントリは、リプレイの前後で変更されません。
oplogの各操作はべき等です。 oplogエントリは、エントリが1回再生されるか複数回再生されるかにかかわらず変更されません。
oplogエントリは、ある期間に関連付けられます。レプリカセットインスタンスのoplogの各操作には、一意のタイムスタンプフィールド (ts) があります。このフィールドは、UNIXタイムスタンプとカウンタで構成されます。このようにして、2つのoplogエントリ間のシーケンスを決定できます。
oplogウィンドウは、oplog内の最も古いoplogエントリと最新のoplogエントリとの間の時間差を示します。プライマリ /セカンダリレプリケーションはoplogウィンドウに依存します。セカンダリノードは、ノードが同期ソースのoplogウィンドウ内の所望のoplogエントリを識別する場合にのみ、期待通りにデータを同期することができます。
レプリカセットインスタンスのセカンダリノードが再起動された後、またはノードがインスタンスに追加された後、ノードはインスタンスのoplog内のoplogエントリにも依存して、ノードがインスタンスの通常のメンバーになることができるかどうかを確認します。ノードが同期ソースのoplogウィンドウ内の所望のoplogエントリを識別しない場合、ノードステータスは、エラーが間に合わないため、RECOVERINGになります。

Oplogサイズ

ApsaraDB for MongoDBレプリカセットまたはシャードクラスターインスタンスのoplogのデフォルトサイズは、インスタンスのディスクストレージの10% です。たとえば、レプリカセットまたはシャードクラスターインスタンスに500 GBのディスクストレージがある場合、インスタンスのoplogサイズは50 GBです。 oplogサイズは、ディスクが拡張されると自動的に調整されます。

oplogサイズを調整するには、ApsaraDB for MongoDBコンソールでreplication.oplogSizeMBパラメーターの値を変更します。変更は、インスタンスを再起動しなくてもすぐに有効になります。設定パラメーターを変更する方法の詳細については、「ApsaraDB For MongoDBインスタンスのデータベースパラメーターの設定」をご参照ください。

次のいずれかの方法を使用して、実際のoplogサイズを表示できます。

ApsaraDB for MongoDBコンソールのインスタンスの [モニタリングデータ] ページで、[ディスク使用量] メトリックの値を表示します。詳細については、「基本モニタリング」をご参照ください。

mongo shellまたはmongoshを使用してインスタンスに接続し、次のコマンドを実行します。

rs.printReplicationInfo()

次の応答が返されます。

configured oplog size:   10.10546875MB
log length start to end: 94400 (26.22hrs)
oplog first event time:  Mon Mar 19 2012 13:50:38 GMT-0400 (EDT)
oplog last event time:   Wed Oct 03 2012 14:59:10 GMT-0400 (EDT)
now:                     Wed Oct 03 2012 15:00:21 GMT-0400 (EDT)

この結果は、oplogサイズが約10 MBであり、oplogウィンドウが約26時間であることを示します。

oplogエントリの最小保持期間

MongoDB 4.4以降では、storage.oplogMinRetentionHoursコンフィギュレーションファイルオプションがサポートされています。このオプションは、oplogエントリの最小保持期間を指定するために使用されます。これにより、十分なoplogウィンドウが確保されます。

オプションのデフォルト値は0で、oplogエントリの最小保持期間が指定されていないことを示します。この場合、oplogエントリは、指定されたoplogサイズに達した後にのみ削除されます。このオプションが設定されている場合、oplogエントリは次の要件が満たされている場合にのみ削除されます。

oplogサイズが、replication.oplogSizeMBパラメーターで指定された値を超えています。
oplogのタイムスタンプは、oplogエントリの最小保持期間よりも前です。

初期化されたインスタンスに大量のデータが書き込まれていない場合など、oplogサイズがreplication.oplogSizeMBパラメーターで指定された値に達していない場合、インスタンスの実際のoplogウィンドウは、oplogエントリの指定された最小保持期間よりもはるかに大きくなる可能性があります。この場合、oplogサイズはreplication.oplogSizeMBパラメーターによってのみ制限されます。 oplogサイズがreplication.oplogSizeMBパラメーターで指定された値に達した後、oplogサイズはoplogエントリの最小保持期間によって制限されます。短時間で多数のoplogエントリが生成された場合、oplogの合計サイズは、replication.oplogSizeMBパラメーターで指定された値よりもはるかに大きくなる可能性があります。

oplogエントリの最小保持期間を調整するには、ApsaraDB for MongoDBコンソールでstorage.oplogMinRetentionHoursパラメーターの値を変更します。変更は、インスタンスを再起動しなくてもすぐに有効になります。設定パラメーターを変更する方法の詳細については、「ApsaraDB For MongoDBインスタンスのデータベースパラメーターの設定」をご参照ください。

インスタンス内のoplogエントリの保持期間を表示するには、ApsaraDB for MongoDBコンソールのインスタンスの [モニタリングデータ] ページで [oplogの保持期間] メトリックの値を表示します。詳細については、「基本モニタリング」をご参照ください。

ApsaraDB for MongoDBインスタンスのログバックアップ操作

すべてのApsaraDB for MongoDBインスタンスのログバックアップ操作は、oplogエントリに基づいて実行されます。インスタンスのログバックアップでは、関連する制御サービスプロセスは、インスタンスから最新のoplogエントリを継続的にプルし、エントリをストリーミングモードでObject Storage service (OSS) にアップロードして、一連のログバックアップファイルを生成します。インスタンスデータが以前の時点に復元されると、ログバックアップファイルを使用して、プルされたoplogエントリが再生されます。

特殊なケースでは、欠落したレコードがログバックアップファイルに生成され、ポイントインタイムの復元に失敗することがあります。詳細については、「リスクの説明」をご参照ください。

説明

ログバックアップファイルに欠落しているレコードには、ApsaraDB for MongoDBのドキュメントに記載されているoplog holeと同じ定義はありません。

ベストプラクティス

適切なoplogサイズまたは保持期間の設定

ほとんどの場合、oplogサイズがデフォルト値です。ただし、次のシナリオでは、oplogサイズを増やすことを推奨します。

ドキュメントのバッチ更新を高頻度で
各バッチ更新操作は、1つのドキュメントに対して複数の更新操作を生成し、多数のoplogエントリを生成します。
繰り返し挿入および削除操作
挿入された文書を一定期間保持してから削除しても、その文書が属するデータベースのディスク容量はそれほど増加しません。しかしながら、多数の関連するoplogエントリがデータベース内に生成されます。
ドキュメントに対する大量のインプレース更新
ビジネスのドキュメントのほとんどの操作が、ドキュメントのサイズを大きくしない更新である場合、更新によって多数のoplogエントリが生成されます。ただし、ディスクのデータ量は大きく変化しません。

次のシナリオでは、oplogサイズを縮小してディスク容量を最大限に活用できます。

読み取り操作が書き込み操作よりも頻繁に実行されるシナリオ。
コールドデータが保存されるシナリオ。

ApsaraDB for MongoDBインスタンスのoplogサイズまたは保持期間を指定するかどうかにかかわらず、インスタンスのoplogウィンドウを24時間以上に設定することを推奨します。追加の同期初期化 (初期同期) が必要なシナリオでは、oplogウィンドウは、ノードが完全なデータ同期を完了するのに必要な時間をカバーする必要があります。ほとんどの場合、時間はインスタンスの全体的なデータ量、データベースとコレクションの総数、インスタンスタイプなどの要因に関連しています。 oplogウィンドウは、より長い期間をカバーすることができます。

セカンダリノードのレプリケーションレイテンシに焦点を当て、レイテンシのアラートルールを設定します

セカンダリノードでレプリケーションレイテンシが発生し、指定されたoplogウィンドウを超えるまで増加し続けると、ノードは異常状態になり、回復できません。したがって、ApsaraDB for MongoDBインスタンスのセカンダリノードのレプリケーションレイテンシに注目する必要があります。レプリケーションのレイテンシが増加し続ける場合、チケットを起票します。

次の理由により、セカンダリノードでレプリケーション遅延が発生します。

ネットワーク待ち時間、パケット損失、または中断。
ボトルネックに達したセカンダリノードのディスクスループット。
書き込みの懸念が {w:1} に設定され、多数の書き込みワークロードがあります。
特定のカーネル欠陥によりブロックされたセカンダリノードのプライマリ /セカンダリレプリケーション。
リストされていないその他の理由。

次のいずれかの方法を使用して、セカンダリノードのレプリケーション遅延を表示できます。

ApsaraDB for MongoDBコンソールのインスタンスの [モニタリングデータ] ページで、[プライマリ /セカンダリレプリケーションの待ち時間] メトリックの値を表示します。詳細については、「基本モニタリング」をご参照ください。
mongo shellまたはmongoshを使用してインスタンスに接続し、次のコマンドを実行します。
```
rs.printSecondaryReplicationInfo()
```
次の応答が返されます。
```
source: m1.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
source: m2.example.net:27017
    syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT)
    0 secs (0 hrs) behind the primary
```
の0秒 (0 hrs)
この結果は、2つのセカンダリノードにレプリケーションレイテンシが存在しないことを示しています。

ApsaraDB for MongoDBコンソールの [アラートルール] モジュールを使用して、レプリケーション待ち時間に関連するアラートルールを作成できます。アラートのしきい値を10秒以上に設定することを推奨します。詳細については、「ApsaraDB For MongoDBインスタンスのしきい値トリガーアラートルールの設定」をご参照ください。

リスク

次の理由により、ログバックアップファイルにレコードが欠落する可能性があります。

インスタンスはMongoDB 3.4より前のメジャーバージョンを実行しています

MongoDB 3.4で定期的なnoopが導入され、readPreferenceのmaxStalenessSecondsパラメーターに適応します。詳細については、「サーバー23892」をご参照ください。定期的なnoopは、データが書き込まれていなくてもoplogエントリが継続的に更新されるように設計されています。これにより、レプリカセットインスタンス内のプライマリノードとセカンダリノードのバックワードネスを判断できます。

インスタンスがMongoDB 3.4より前のメジャーバージョンを実行し、長期間インスタンスにデータが書き込まれない場合、oplogエントリは更新されません。したがって、インスタンスのログバックアップファイルは新しいoplogデータを取得できず、ファイル内のレコードが欠落します。この場合、インスタンスデータを以前の時点に復元することはできません。

大量のデータが短時間インスタンスに書き込まれ、インスタンスのoplogウィンドウの期間が短くなります

ApsaraDB for MongoDBで長期間生成されたログバックアップデータは、インスタンスのoplog生成速度が約250GB/h〜330GB/hに達すると、ログバックアップファイルが生成されたoplogエントリをタイムリーに収集できず、ファイル内のレコードが欠落する可能性があることを示しています。

oplogのサイズとoplogウィンドウに基づいてoplog生成速度を推定できます。たとえば、インスタンスのoplogサイズが20 GBで、インスタンスのoplogウィンドウが0.06時間の場合、oplog生成速度は約333.3 GB/hです。

次のシナリオでは、高いワークロードが生成されます。

Data Transmission Service (DTS) 、mongoShake、またはその他のデータ同期ツールがデータを同期します。
大量のINSERTまたはUPDATE操作は、短時間でバッチで実行されます。
大量のデータがデータベースに書き込まれます。
ストレステストを実施します。

大量のデータが長期間書き込まれたためにログバックアップファイルにレコードが欠落しないようにするには、次の最適化手段を使用することを推奨します。

同期ツールを使用する場合は、データの書き込み速度を制限する必要があります。たとえば、同時実行とバッチサイズを制限する必要があります。
書き込みに関する問題は、{w:1} ではなく {w:"majority"} に設定する必要があります。

ワークロードでoplogの生成速度が常に高い場合は、次の最適化手段を使用することを推奨します。

シャードクラスタインスタンスを使用するか、シャードの数を増やして、単一のシャードでのoplog生成速度を低下させます。
ログバックアップファイルのバッファ期間を長く確保するために、ビジネスシナリオに基づいてoplogサイズまたはoplogエントリの最小保持期間を増やします。このようにして、ログバックアップファイルは、欠落しているoplogエントリをタイムリーに収集できます。

ApsaraDB for MongoDB:oplog設定のベストプラクティスとリスク