mongosyncカットオーバー プロセスを使用して、移行を完了し、アプリケーション ワークロードをソース クラスターから宛先クラスターに転送できます。
警告
移行 をコミットする前に書込みを確実に停止するには、以下の手順を実行する必要があります。
"majority"移行を通じてソースクラスター上の同期されたコレクションに書き込まれるすべてのアプリケーション書き込みに 書込み保証 (write concern)を使用します。同期されたコレクションへのすべての書き込みを正常にシャットダウンします。
それ以外の場合、カットオーバーが開始された後に書込み (write) を適用できます。
カットオーバーの進行中に書込み (write) が適用されると、
mongosyncは書込みを検出します。移行は永続的に失敗するため、再度実行する必要があります。カットオーバーが完了した後に書込み (write) が適用された場合、
mongosyncはそれらを検出しません。これらの書込み (write) は失われ、移行によって暗黙的にデータが破損します。
mongosync は、 COMPUTED 状態に達するまでアクティブなままである必要があります。これにより、mongosync は移行中に発生する追加の書込みを同期できるようになります。
注意
アプリケーションのワークロードを宛先クラスターに切り替える前に、常に同期が成功していることを確認する必要があります。 詳細については、「 データ転送を確認する 」を参照してください。
手順
mongosync のステータスを確認します。
カットオーバー プロセスを開始する前に、プログレスエンドポイントを呼び出して、 mongosyncのステータスを判断します。 mongosyncプロセス ステータスが次の値を示していることを確認します。
canCommitはtrueです。lag.overallLagSecondsは小さい値（0に近い値）です。カットオーバーの開始時に
lag.overallLagSecondsが0に近くない場合、カットオーバーに長い時間がかかる可能性があります。
次の例では、同期プロセスのステータスを返します。
リクエスト
curl localhost:27182/api/v1/progress -XGET応答
{ "progress": { "state":"RUNNING", "canCommit":true, "canWrite":false, "info":"change event application", "ceaStage":"steady state", "lag": { "overallLagSeconds": 0, "crudLagSeconds": 0, "ddlLagSeconds": null }, "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 がクラッシュした場合は、次のコマンドを実行中てソースクラスターへの書き込み (write) のブロックを手動で解除する必要がある場合があります。
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"truesetUserWriteBlockMode を使用して宛先クラスターでの書き込み (write)を手動でブロックした場合は、宛先クラスターでアプリケーション書き込み (write)を有効にします。
書込みを有効にするには、 setUserWriteBlockModeを更新します。
db.adminCommand( { setUserWriteBlockMode: 1, global: false })その後、アプリケーションワークロードを宛先クラスターに転送します。
宛先クラスター上のメタデータデータベースを削除します。
mongosync は、移行中にデータベースつまたは複数のデータベースにメタデータを保存します。メタデータデータベースには、次のいずれかの名前を付けることができます。
__mdb_internal_mongosyncで始まるのもの
__mdb_internal_mongosync_verifier
移行が成功させるたら、メタデータデータベースを削除します。
警告
reversible を true に設定して移行を開始した場合、メタデータデータベースを削除した後に移行を元に戻すことはできません。
mongosh で、宛先クラスター上の各メタデータデータベースを削除します。
use <database-name>db.dropDatabase()動作
canWrite と Committed
mongosync は、COMMITTED 状態よりも前の段階で宛先クラスターへの書込みを許可します。
/progress が canWrite: true を報告した後、または状態が COMMITTED の場合に、宛先に書き込みを行えます。書き込み (write) ブロックの詳細については、書き込み (write) ブロック を参照してください。mongosync の複数のインスタンスを実行中いる場合は、最初の mongosync プロセスの canWrite ステータスのみを使用します。
最初の同期では、mongosync はソースクラスター上の一意のインデックスを宛先クラスターの非一意のインデックスとして複製します。コミット中、宛先クラスター上の関連する非一意のインデックスは prepareUnique に設定されます。これが完了すると、/progress エンドポイントは canWrite: true を返し始める。prepareUnique インデックスを持つコレクションは、ユニークインデックス制約に違反する新しいドキュメントを拒否します。mongosync は 次に、prepareUnique インデックスを一意のインデックスに変換します。これが完了すると、mongosync は状態を COMMITTED に変わります。
注意
大規模なコレクションを同期する場合、prepareUnique インデックスから一意のインデックスへの変換はリソースを集中的に消費する可能性があります。これにより、/progress エンドポイントが canWrite: true を返してから mongosync が COMMITTED 状態に達するまでに長い時間がかかる可能性があります。
アプリケーションは canWrite: true が返された後に書き込みを発行できますが、インデックスのビルドなどの排他ロックを必要とする操作は、インデックスの変換が完了した後にのみ続行できます。さらに、リソースの競合により、この時間中に書込み (write) 操作のレイテンシが増加する可能性があります。