ApsaraDB for MongoDB インスタンスの oplog パラメーターが不適切に設定されていると、プライマリ/セカンダリ間のレプリケーションに問題が発生し、ポイントインタイムリストアが妨げられる可能性があります。このトピックでは、oplog パラメーターの設定方法と関連するリスクについて説明します。
概要
ApsaraDB for MongoDB のレプリカセットインスタンスは、プライマリ/セカンダリ間のレプリケーションにオペレーションログ (oplog) を使用します。oplog テーブルである local.oplog.rs は、データベース内のドキュメントを変更するすべての操作を格納する特殊な 固定コレクション です。oplog には、次の基本的な属性があります：
レプリカセットでは、書き込み操作はプライマリノードでのみ行われ、対応する oplog エントリが生成されます。その後、セカンダリノードはこれらのエントリを非同期にレプリケートして再生し、レプリケーションの状態を維持します。
操作がドキュメントを変更しない場合や、何らかの理由で失敗した場合は、oplog レコードは生成されません。
oplog レコードは、レプリカセット内のすべてのノードで同一です。エントリを再生しても、oplog テーブル内のレコードは変更されません。
oplog テーブル内のすべての操作はべき等です。つまり、oplog レコードを 1 回再生しても複数回再生しても、結果は同じです。
oplog レコードは時間に依存します。oplog 内の各操作には、UNIX タイムスタンプとカウンターで構成される一意のタイムスタンプ (ts) フィールドがあります。これにより、任意の 2 つの oplog レコードの順序を判断できます。
oplog ウィンドウは、oplog テーブル内の最も古いレコードと最も新しいレコードの間の時間差です。プライマリ/セカンダリ間のレプリケーションはこのウィンドウに依存します。セカンダリノードは、同期ソースの oplog ウィンドウ内で必要な oplog レコードを見つけた場合にのみ、正常に同期できます。セカンダリノードが再起動したり、新しいノードが追加されたりすると、oplog レコードに依存してレプリカセットに正常に参加できるかを確認します。同期ソースで必要な oplog レコードが見つからない場合、ノードは異常な RECOVERING 状態になり、
too stale to catch upエラーが報告されます。
Oplog サイズ
ApsaraDB for MongoDB では、デフォルトの oplog サイズはインスタンスのディスク領域の 10% です。たとえば、インスタンスのディスク領域が 500 GB の場合、oplog サイズは 50 GB です。ディスク領域を拡張すると、oplog サイズは自動的に調整されます。
コンソールで replication.oplogSizeMB パラメーターを変更することで、oplog サイズを調整できます。変更は送信後すぐに有効になり、再起動は不要です。設定パラメーターの変更方法の詳細については、「データベースパラメーターの設定」をご参照ください。
oplog テーブルの実際のサイズは、次の 2 つの方法で確認できます：
コンソールのモニタリング情報ページで [ディスク使用量] メトリックを確認できます。 詳細については、「ノードモニタリング (旧基本モニタリング)」をご参照ください。
`mongo shell` や `mongosh` などのクライアントツールを使用してインスタンスに接続します。その後、次のコマンドを実行して、oplog テーブルのサイズと oplog ウィンドウを表示できます。
rs.printReplicationInfo()出力例を次に示します。
configured oplog size: 192MB log length start to end: 65422secs (18.17hrs) oplog first event time: Mon Jun 23 2014 17:47:18 GMT-0400 (EDT) oplog last event time: Tue Jun 24 2014 11:57:40 GMT-0400 (EDT) now: Thu Jun 26 2014 14:24:39 GMT-0400 (EDT)この例では、oplog サイズは約 192 MB、oplog ウィンドウは約 18 時間です。
Oplog の最小保持期間
MongoDB 4.4 以降、storage.oplogMinRetentionHours 設定項目がサポートされています。この項目により、oplog の保持期間を直接制御して、十分な oplog ウィンドウを確保できます。
デフォルトでは、この設定項目は 0 に設定されており、oplog の最小保持期間が設定されていないことを意味します。この場合、oplog のクリーンアップは oplog サイズによって制御されます。この設定項目を設定した場合、oplog のクリーンアップは、次の両方の条件が満たされた場合にのみ行われます：
oplog が設定された
oplogSizeMBを超えている。oplog のタイムスタンプが最小保持期間よりも古い。
インスタンスが新しく初期化され、まだ多くのデータが書き込まれていない場合など、oplog が設定された oplogSizeMB に達していない場合、実際の oplog ウィンドウは設定された最小保持期間を超えることがあります。この場合、oplog テーブルのサイズは oplogSizeMB によってのみ制限されます。設定された oplogSizeMB に達した後、oplog テーブルのサイズは最小保持期間によって制限されます。oplog エントリが急速に生成される場合、oplog の合計サイズは設定された oplogSizeMB よりもはるかに大きくなる可能性があります。
コンソールで storage.oplogMinRetentionHours パラメーターを変更することで、oplog の保持期間を調整できます。変更は送信後すぐに有効になり、再起動は不要です。設定パラメーターの変更方法の詳細については、「データベースパラメーターの設定」をご参照ください。
oplog の保存期間を表示するには、コンソールの監視ページで [Oplog の保存期間] メトリックを確認できます。 詳細については、「ノード監視 (旧称: 基本監視)」をご参照ください。
ApsaraDB for MongoDB のログバックアップ
すべての ApsaraDB for MongoDB インスタンスのログバックアップは oplog に基づいています。コントロールサービスプロセスは、インスタンスから最新の oplog レコードを継続的にプルし、OSS にストリーミングアップロードを実行します。このプロセスにより、一連のログバックアップファイルが作成されます。ポイントインタイムリストア中、これらのログバックアップファイルは oplog の再生に使用されます。
特殊なケースでは、ログバックアップに 欠落 が発生し、ポイントインタイムリストアが妨げられることがあります。詳細については、「リスク」をご参照ください。
このトピックで言及されているログバックアップの欠落は、MongoDB の用語である oplog hole とは異なります。
ベストプラクティス
Oplog サイズと保持期間の設定
通常はデフォルトの oplog サイズを維持できます。ただし、次のシナリオのワークロードでは、oplog サイズを増やす必要があります：
ドキュメントへの頻繁な一括更新
各一括更新操作は、個々のドキュメントに対して複数の更新操作を生成します。これにより、多くの oplog レコードが生成されます。
繰り返される挿入と削除
ドキュメントが挿入されてからしばらくして削除される場合、データベースのディスク領域は大幅に増加しませんが、oplog には多くの関連レコードが含まれます。
同じドキュメントへの多数のインプレース更新
ビジネスシナリオのほとんどの操作がドキュメントサイズを増加させない更新である場合、これらの更新は多くの oplog レコードを生成しますが、ディスク上のデータ量は大幅に変化しません。
ワークロードが次のいずれかのタイプである場合は、必要に応じて oplog サイズを減らして、ディスク領域をより有効に活用することもできます：
読み取りが多く、書き込みが少ないワークロード。
コールドデータの保存。
oplog サイズまたは oplog の保持期間のいずれを設定する場合でも、MongoDB インスタンスの oplog ウィンドウは 24 時間以上に維持する必要があります。追加の 初期同期 が必要な一部のシナリオでは、oplog ウィンドウはノードがデータ同期を完了するのにかかる時間をカバーする必要があります。この時間は通常、インスタンスの総データ量、データベースとコレクションの総数、インスタンスタイプなどの要因によって異なります。このような場合、oplog ウィンドウをより長くする必要がある場合があります。
レプリケーション遅延の監視とアラート設定
セカンダリノードでレプリケーション遅延が発生し、設定された oplog ウィンドウを超えるまで増加すると、ノードは異常な状態になり、回復できなくなります。したがって、MongoDB インスタンスのセカンダリノードの遅延を監視する必要があります。遅延が増加し続ける場合は、速やかにチケットを起票して、Alibaba Cloud テクニカルサポートに支援をリクエストしてください。
セカンダリノードの遅延には、次のような多くの理由があります：
ネットワークの遅延、パケット損失、または中断。
セカンダリノードのディスクスループットがボトルネックに達している。
書き込みワークロードが重い場合の書き込み確認
{w:1}。特定のカーネルバグがセカンダリノードでのプライマリ/セカンダリ間のレプリケーションをブロックしている。
その他の理由。
セカンダリノードの遅延は、次の 2 つの方法で確認できます：
コンソールのモニタリングページで [プライマリ/セカンダリレプリケーションレイテンシー] メトリックを確認できます。詳細については、「ノードモニタリング (旧基本モニタリング)」をご参照ください。
`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この例では、2 つのセカンダリノードのどちらにも遅延はありません。
コンソールでは、[アラートルール] 機能を使用して、[ReplicationLag] のしきい値を 10 秒以上として CloudMonitor アラートを作成できます。 詳細については、「しきい値ベースのアラートルールを設定する」をご参照ください。
リスク
次のセクションでは、ログバックアップに欠落が発生する可能性のある 2 つの主な理由について説明します。
MongoDB バージョン < 3.4
MongoDB メジャーバージョン 3.4 で、`readPreference` の maxStalenessSeconds パラメーターをサポートするために、定期的な no-op (no operation) オペレーションが導入されました。詳細については、「SERVER-23892」をご参照ください。この no-op の主な目的は、ビジネスの書き込みがない場合でも oplog が進み続けることを保証することです。これにより、レプリカセット内のセカンダリノードがどれだけ遅れているかを判断するのに役立ちます。
データベースのメジャーエンジンバージョンが 3.4 より前の場合、長期間ビジネスの書き込みがないと oplog は進みません。その結果、インスタンスのログバックアップは新しい oplog データを取得できず、ログバックアップの欠落が発生します。これにより、インスタンスを特定の時点に復元できなくなります。
書き込み速度が速く、oplog ウィンドウが短い場合
ApsaraDB for MongoDB インスタンスの過去のログバックアップデータに基づくと、インスタンスの oplog 生成速度が約 125 GB/h から 165 GB/h に達すると、ログバックアッププロセスが追いつけなくなり、ログバックアップの欠落が発生する可能性が非常に高くなります。
前述の oplog サイズと oplog ウィンドウを使用して、oplog の生成速度を見積もることができます。たとえば、インスタンスの oplog サイズが 20 GB で、oplog ウィンドウが 0.06 時間の場合、その oplog 生成速度は約 333.3 GB/h です。
このようなワークロードは、通常、次のシナリオで発生します：
`DTS`、`mongoShake`、またはその他のデータ同期ツールを使用してデータが同期されている。
多くのバッチ INSERT または UPDATE 操作が短時間でロードされる。
データシーディング (大量のデータをデータベースに迅速にインポートする)。
ストレステスト。
過度に高い書き込み速度によるログバックアップの欠落を防ぐために、次の最適化メジャーを検討できます：
同期ツールを使用する場合は、同時実行数やバッチサイズなどの適切なレート制限を適用します。
書き込み確認には、
{w:1}の代わりに{w:"majority"}を使用します。
ワークロードが本質的に高い oplog 生成速度を持つ場合は、代わりに次の最適化アプローチを検討できます：
シャードクラスターインスタンスを使用するか、シャードの数を増やして、単一のシャードでの oplog 生成速度を低下させます。
ビジネスシナリオに応じて、oplog サイズまたは oplog の最小保持期間を増やします。これにより、ログバックアッププロセスのためのより長いバッファー時間が提供されます。これにより、ワークロードが減少したときに、ログバックアッププロセスが以前に遅れていた oplog レコードに追いつくことができます。