oplog のサイジング
mongosyncプログラムは変更ストリームを使用して、ソースクラスターと宛先クラスター間でデータを同期します。 mongosyncはoplogに直接アクセスしませんが、変更ストリームが過去のイベントを返す場合、そのイベントはoplogの時間範囲内である必要があります。
mongosync は、コレクションコピー フェーズ後に、ソースクラスターの oplog の操作を宛先クラスターのデータに適用します。mongosync が適用していなかった操作がソースクラスターの oplog をロールオフすると、同期は失敗し、mongosync は終了します。
注意
mongosyncは、宛先クラスターへの同期中にソースクラスターで行われたapplyOps操作を複製しません。
大規模なデータセットの同期が予想される場合、または同期を長期間にわたって一時停止する予定の場合、 oplog windowを超える可能性があります。 ソースクラスター上のoplogのサイズを増やすには、 oplogSizeMB設定を使用します。
Considerations
宛先クラスターには、移行される論理データ サイズと最初の同期の宛先oplogエントリーに十分対応できるディスクストレージが必要です。 例、10 GBのデータを移行するには、宛先クラスターでデータには少なくとも 10 GBが使用可能であり、最初の同期からの挿入oplogエントリ用にはさらに 10 GB が必要です。
埋め込み検証 を使用するには、宛先のoplogがより大きくなければなりません。埋め込み検証子を有効にして宛先oplogのサイズを減らすと、埋め込み検証子が追いつけない可能性があり、mongosync がエラーを発生させる可能性があります。
宛先oplogエントリのオーバーヘッドを減らす必要があり、埋め込み検証子が無効になっている場合は、次の操作を実行できます。
oplogSizeMB宛先クラスターのoplogサイズを小さくするには、 設定を使用します。oplogMinRetentionHoursを使用して 設定を解除し、宛先クラスターの最小oplog保持期間を短縮または削除します。
最初の同期に必要な oplog サイズを監視する
oplog window の決定
oplogの最初と最後のエントリの差を秒単位で取得するには、 db.getReplicationInfo()を実行します。 シャーディングされたクラスターをレプリケートする場合は、各シャードで コマンドを実行します。
db.getReplicationInfo().timeDiff
返される値は、クラスターの最小oplogウィンドウです。 シャードが複数ある場合、最小の数は最小のoplogウィンドウです。
mongosync レプリケーションラグの決定
lagTimeSeconds値を取得するには、 /progressコマンドを実行します。 ラグタイムは、 mongosyncによって適用された最後のイベントとソースクラスター上の現在の最新イベントの時間までの時間（秒単位）です。
これは、ソースクラスターmongosyncがどれだけ遅れているかを測定します。
oplog サイズの検証
ラグ時間が最小oplogウィンドウに近づく場合は、次のいずれかを変更します。
oplogウィンドウを増やします。replSetResizeOplogを使用して、minRetentionHoursを現在のoplogウィンドウよりも大きく設定します。注意
replSetResizeOplogAtlas では はサポートされていません。Atlas でoplog のサイズを変更するには、「 最小oplog ウィンドウ の設定 」を参照してください。mongosyncインスタンスをスケールアップします。 CPU またはメモリを追加してmongosyncノードをスケールアップし、コピー率を高めます。
注意
レプリケーションラグのoplog window と変化率は、同期中に変化する可能性があります。 移行中にこれらの手順を繰り返し、進行状況を監視します。