mongosyncカットオーバー プロセスを使用して、移行を完了し、ソースクラスターから宛先クラスターにアプリケーション ワークロードを転送できます。
mongosync は、 COMPUTED 状態に達するまでアクティブなままである必要があります。これにより、mongosync は移行中に発生する追加の書込みを同期できるようになります。
注意
アプリケーションのワークロードを宛先クラスターに切り替える前に、常に同期が成功していることを確認する必要があります。 詳細については、「 データ転送を確認する 」を参照してください。
手順
mongosync のステータスを確認します。
カットオーバー プロセスを開始する前に、プログレスエンドポイントを呼び出して、 mongosyncのステータスを判断します。 mongosyncプロセス ステータスが次の値を示していることを確認します。
canCommitはtrueです。lagTimeSecondsは小さい値（0に近い値）です。カットオーバーの開始時に
lagTimeSecondsが0に近くない場合、カットオーバーに長い時間がかかる可能性があります。verification.source埋め込み検証子を使用する場合は、verification.destinationと が返すドキュメントの両方を確認します。両方のドキュメントのlagTimeSecondsフィールドは0に近く、phaseフィールドには"stream hashing"が表示される必要があります。検証子がストリーム ハッシュ フェーズにない場合、カットオーバー プロセスに長い時間がかかる可能性があります。
次の例では、同期プロセスのステータスを返します。
リクエスト
curl localhost:27182/api/v1/progress -XGET
応答
{ "progress": { "state":"RUNNING", "canCommit":true, "canWrite":false, "info":"change event application", "lagTimeSeconds":0, "collectionCopy": { "estimatedTotalBytes":694, "estimatedCopiedBytes":694 }, "directionMapping": { "Source":"cluster0: localhost:27017", "Destination":"cluster1: localhost:27018" }, "source": { "pingLatencyMs":250 }, "destination": { "pingLatencyMs":-1 }, "verification": { "source": { "estimatedDocumentCount": 42, "hashedDocumentCount": 42, "lagTimeSeconds": 2, "totalCollectionCount": 42, "scannedCollectionCount": 10, "phase": "stream hashing" }, "destination": { "estimatedDocumentCount": 42, "hashedDocumentCount": 42, "lagTimeSeconds": 2, "totalCollectionCount": 42, "scannedCollectionCount": 10, "phase": "stream hashing" } } }, "success": true }
ソース上の同期されたコレクションへの書込み操作を停止します。
ソースクラスター上のすべてのトランザクションがコミットまたは中止されるまで待機します。
mongosyncは、移行構成に基づいて書込みブロックを管理します。詳しくは、「 書込みブロック 」を参照してください。mongosyncがフィルタリングされた同期を使用する場合、ソースクラスター全体への書込みを無効にする必要はありません。 ただし、フィルターに含まれるコレクションの書込み (write) 操作は、必ず停止する必要があります。
mongosync に コミット リクエストを送信します。
移行のために複数の mongosync インスタンスを起動する場合は、mongosyncインスタンスごとにコミットリクエストを発行する必要があります。
リクエスト
curl localhost:27182/api/v1/commit -XPOST --data '{ }'
応答
{"success":true}
注意
commitリクエストを送信した後、 progressエンドポイントを呼び出して、 mongosyncの状態がCOMMITTINGまたはCOMMITTEDであることを確認します。
ソースクラスターに永続クエリ設定（PQS）が含まれている場合は、PQS を宛先クラスターに手動で移行する必要があります。
mongosyncデフォルト構成では、このステップが完了すると、 はソースクラスターへの書込みをブロックします。
このステップの実行中に mongosync がクラッシュした場合は、次のコマンドを実行中てソースクラスターへの書込みのブロックを手動で解除する必要がある場合があります。
db.adminCommand( { setUserWriteBlockMode: 1, global: false } )
宛先クラスターで書込み (write) を実行できるまで待ちます。
progress エンドポイントとなる接続されたデバイスを呼び出して、canWrite が true であるかどうかを確認します。canWrite が false の場合は、progress が canWrite が true であることを示すまで待ちます。複数の mongosync インスタンス を実行中いる場合は、最初の mongosync プロセスで canWrite が true であることのみを確認してください。後続の mongosync プロセスの canWrite ステータスが無効です。
curl -sS localhost:27182/api/v1/progress -XGET | jq ".progress.canWrite"
true
データ転送を確認します。
ソースクラスターから宛先クラスターへのデータの同期が成功したことを確認します。
詳細については、「データ転送を確認する 」を参照してください。
setUserWriteBlockModeを使用して宛先クラスターへの書込みを手動でブロックした場合は、宛先クラスターでアプリケーション書込みを有効にします。
書込みを有効にするには、 setUserWriteBlockModeを更新します。
db.adminCommand( { setUserWriteBlockMode: 1, global: false } )
その後、アプリケーションワークロードを宛先クラスターに転送します。
動作
canWrite と Committed
mongosync は、COMMITTED 状態よりも前の段階で宛先クラスターへの書込みを許可します。
が/progress canWrite: trueを報告した後、または状態がCOMMITTED の場合に、宛先に書き込みを行えます。書込み (write) ブロックの詳細については、「 書込み (write) ブロック 」を参照してください。mongosync の複数のインスタンスを実行中いる場合は、最初のcanWrite mongosyncプロセスの ステータスのみを使用します。
最初の同期では、mongosync はソースクラスター上の一意のインデックスを宛先クラスターの非一意のインデックスとして複製します。コミット中、宛先クラスター上の関連する非一意のインデックスは prepareUnique に設定されます。これが完了すると、/progress エンドポイントは canWrite:
true を返し始める。prepareUnique インデックスを持つコレクションは、ユニークインデックス制約に違反する新しいドキュメントを拒否します。mongosync は 次に、prepareUnique インデックスを一意のインデックスに変換します。これが完了すると、mongosync は状態を COMMITTED に変わります。
注意
大規模なコレクションを同期する場合、prepareUnique インデックスから一意のインデックスへの変換はリソースを集中的に消費する可能性があります。これにより、/progress エンドポイントが canWrite: true を返してから mongosync が COMMITTED 状態に達するまでに長い時間がかかる可能性があります。
アプリケーションは canWrite:
true が返された後に書き込みを発行できますが、インデックスのビルドなどの排他ロックを必要とする操作は、インデックスの変換が完了した後にのみ続行できます。さらに、リソースの競合により、この時間中に書込み (write) 操作のレイテンシが増加する可能性があります。