すべてのプロダクト
Search

このプロダクト

    ApsaraDB for MongoDB:Oplog のベストプラクティスとリスク

    ドキュメントセンター

    ApsaraDB for MongoDB:Oplog のベストプラクティスとリスク

    最終更新日:Jun 04, 2026

    ApsaraDB for MongoDB インスタンスの oplog パラメーターが不適切に構成されていると、プライマリノードとセカンダリノード間のレプリケーションが異常になったり、ポイントインタイムリストアが実行できなくなったりする可能性があります。oplog パラメーターの構成方法と関連するリスクについて説明します。

    概要

    ApsaraDB for MongoDB のレプリカセットインスタンスでは、operations log（操作ログ）である oplog を通じてデータをレプリケーションします。この oplog は capped collection（上限付きコレクション）であり、local.oplog.rs という名前で、すべてのドキュメント更新操作を記録します。主な特徴は以下のとおりです。

    • プライマリノードでの書き込み操作により oplog エントリが生成されます。セカンダリノードはこれらのエントリを非同期でレプリケーションし、再実行することで同期を維持します。

    • ドキュメントを更新しない操作や失敗した操作は、oplog エントリを生成しません。

    • oplog エントリはレプリカセットのすべてのメンバーで同一です。エントリを適用しても、そのエントリ自体は変更されません。

    • すべての oplog 操作はべき等性（idempotent）を持ち、1 回適用しても複数回適用しても結果は同じです。

    • oplog エントリは時系列順に並んでいます。各エントリには UNIX タイムスタンプと増分カウンターを組み合わせた一意のタイムスタンプフィールド（ts）があり、厳密な順序付けを保証します。

    • oplog window（oplog ウィンドウ）とは、最も古いエントリと最新のエントリの間の時間幅です。セカンダリノードは、必要な開始エントリがレプリケーション元の oplog ウィンドウ内にある場合にのみ同期できます。

    • 再起動後または新しく追加されたノードも、レプリカセットに参加するために oplog エントリに依存します。必要なエントリが存在しない場合、ノードは異常な RECOVERING 状態となり、too stale to catch up エラーが発生します。

    Oplog サイズ

    ApsaraDB for MongoDB では、デフォルトの oplog サイズはディスク領域全体の 10% です。たとえば、500 GB のディスクでは oplog サイズは 50 GB になります。ディスク領域を増やすと、oplog も自動的に拡張されます。

    oplog サイズを調整するには、コンソールで replication.oplogSizeMB パラメーターを変更します。変更は再起動不要で即時に有効になります。データベースパラメーターの設定。

    oplog テーブルサイズを確認するには:

    • コンソールのモニタリングページで Disk Space Usage メトリックを確認します。ノードモニタリング（旧称：基本モニタリング）。

    • mongo shell または mongosh で接続し、次のコマンドを実行します。

      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)

      上記の例では、192 MB の oplog で oplog ウィンドウが 18 時間であることを示しています。

    最小 oplog 保持期間

    MongoDB 4.4 では、最小 oplog 保持期間を制御し、十分な oplog ウィンドウを確保するための storage.oplogMinRetentionHours パラメーターが導入されました。

    デフォルト値は 0（最小保持期間なし。クリーンアップは oplog サイズによって制御される）です。この値を設定すると、以下の両方の条件を満たす場合にのみ oplog のクリーンアップが実行されます。

    • oplog 使用量が設定された oplogSizeMB を超えていること。

    • エントリのタイムスタンプが最小 oplog 保持期間より古いこと。

    oplog が oplogSizeMB（たとえば、新規インスタンスの場合）に達する前は、実際の oplog ウィンドウが設定された最小保持期間を超える可能性があり、サイズは oplogSizeMB のみによって制限されます。oplogSizeMB に到達した後は、保持期間がクリーンアップを制御します。書き込みレートが高いと、oplog が oplogSizeMB を大幅に超えて成長する可能性があります。

    保持期間を調整するには、コンソールで storage.oplogMinRetentionHours を変更します。変更は再起動不要で即時に有効になります。データベースパラメーターの設定。

    保持期間を確認するには、コンソールのモニタリングページで Oplog保持期間 メトリックを確認します。ノードモニタリング（旧称：基本モニタリング）。

    ApsaraDB for MongoDB のログバックアップ

    ApsaraDB for MongoDB インスタンスのログバックアップは oplog を使用します。専用プロセスが継続的に最新の oplog エントリをフェッチし、Object Storage Service (OSS) にログバックアップファイルとしてストリーミングします。ポイントインタイムリストア時には、これらのファイルを使って oplog を再実行します。

    特定の状況下では、ログバックアップにホール（穴）が生じ、ポイントインタイムリストアができなくなることがあります。リスク。

    説明

    ここで説明するログバックアップホールは、MongoDB のoplog holeとは異なります。

    ベストプラクティス

    Oplog サイズまたは保持期間の構成

    デフォルトの oplog サイズは、ほとんどのワークロードで十分です。以下のシナリオでは、サイズを増やすことを検討してください。

    • 頻繁な一括更新

      一括更新の各操作は個別の複数の操作を生成し、多くの oplog エントリを生成します。

    • 頻繁な挿入および削除

      ディスク使用率は安定していますが、挿入および削除の両方の操作に対して oplog エントリが蓄積されます。

    • 同一ドキュメントへの多数のインプレース更新

      ドキュメントサイズを増加させない更新は、ディスク使用率に顕著な変化をもたらさずに多数の oplog エントリを生成します。

    以下のケースでは、oplog サイズを小さくすることを検討してください。

    • 読み取りが中心で書き込みが少ないワークロード。

    • コールドデータの保存。

    oplog ウィンドウは 24 時間以上に保つことを推奨します。初期同期のシナリオでは、ウィンドウが全データのコピーに必要な時間をカバーしている必要があります。この時間はデータ量、コレクション数、インスタンスの仕様に依存します。このようなケースでは、より長い oplog ウィンドウが必要になる場合があります。

    セカンダリノードの遅延モニタリングとアラート設定

    レプリケーションラグが oplog ウィンドウを超えると、セカンダリノードは回復不能なエラー状態になります。レプリケーションラグをモニタリングし、ラグが継続的に増加する場合は速やかにチケットを送信してください。

    一般的な原因は以下のとおりです。

    • ネットワーク遅延、パケット損失、または通信途絶。

    • セカンダリノードのディスクスループットがボトルネックになっている。

    • 書き込み負荷が高く、かつ書き込み確認レベル（write concern）が {w:1} に設定されている。

    • セカンダリノード上でプライマリ・セカンダリ間のレプリケーションをブロックするカーネルの欠陥。

    • その他の未記載の理由。

    レプリケーションラグを確認するには:

    • コンソールのモニタリングページで プライマリ/セカンダリ レプリケーション遅延 メトリックを確認します。ノードモニタリング（旧称：基本モニタリング）。

    • 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

      両方のセカンダリノードのレプリケーションラグがゼロであることを示しています。

    レプリケーション遅延 メトリックに対して、Alarm Rules 機能を使用して CloudMonitor アラートを作成します。しきい値は 10 秒以上に設定してください。しきい値ベースのアラートルールの設定。

    リスク

    ログバックアップホールが発生する主な原因は以下の 2 つです。

    MongoDB 3.4 より前のバージョン

    MongoDB 3.4 では、maxStalenessSeconds 読み取りプリファレンスパラメーターをサポートするために、定期的な no-op 書き込みが導入されました（SERVER-23892）。これらの no-op 書き込みにより、アイドル期間中でも oplog が進展し、セカンダリノードの正確な遅延測定が可能になります。

    3.4 より前のバージョンでは、アイドル期間中に oplog の進展が停止します。そのため、ログバックアッププロセスが新しいデータをフェッチできず、ポイントインタイムリストアを妨げるバックアップホールが発生します。

    書き込みレートが高く oplog ウィンドウが短い

    ApsaraDB for MongoDB インスタンスからのデータによると、oplog 生成レートがおよそ 125 GB/h ～ 165 GB/h に達すると、ログバックアッププロセスが遅れ、バックアップホールが発生する可能性が非常に高くなります。

    生成レートは、oplog サイズを oplog ウィンドウで割ることで推定できます。たとえば、20 GB の oplog で 0.06 時間のウィンドウの場合、約 333.3 GB/h となります。

    典型的なシナリオは以下のとおりです。

    • DTS、mongoShake などのツールによるデータ同期。

    • 短時間で大量の INSERT または UPDATE 操作を実行するバッチ処理。

    • データシーディング（高速バルクインポート）。

    • 負荷テスト。

    書き込みレートが高いためにバックアップホールを防ぐには、以下の対策を講じてください。

    • 同時実行数やバッチサイズを調整して、同期ツールにレート制限を適用します。

    • 書き込み確認レベル（write concern）として {w:"majority"} を使用し、{w:1} を避けてください。

    本来的に oplog 生成レートが高いワークロードの場合:

    • シャードクラスターを使用するか、シャードを追加して oplog 生成レートを分散します。

    • oplog サイズまたは最小保持期間を増やして、トラフィックが少ない時間帯にバックアッププロセスが追いつけるようにバッファーを確保します。

    参照