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 と変化率は、同期中に変化する可能性があります。 移行中にこれらの手順を繰り返し、進行状況を監視します。