您可以完成迁移，并使用mongosync切换进程将应用程序工作负载从源集群转移到目标集群。
警告
为了在提交迁移之前可靠地停止写入，您必须：
在整个迁移过程中，对源集群上同步集合的所有应用程序写入使用
"majority"写关注（write concern）。彻底关闭所有对同步集合的写入操作。
否则，写入可能会在切换开始后应用。
如果迁移正在进行时执行了写入操作，
mongosync会检测到该写入。迁移永久失败，您必须重新执行迁移。如果写入在切换完成后应用，
mongosync将无法检测到它们。这些写入会丢失，迁移会静默损坏您的数据。
mongosync 应保持活动状态，直到达到 COMMITTED 状态。这允许 mongosync同步迁移期间发生的任何其他写入。
注意
在将应用程序工作负载切换到目标集群之前，应始终验证同步是否成功。 有关详细信息，请参阅验证数据传输。
步骤
验证 mongosync 的状态。
在开始切换进程之前，调用进度端点以确定mongosync的状态。 确保mongosync进程状态显示以下值：
canCommit是true。lag.overallLagSeconds很小（接近0）。如果在转换开始时
lag.overallLagSeconds不接近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", "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使用筛选同步，则无需禁用对整个源集群的写入。 但是，您必须确保停止对过滤包含的集合的写入操作。
向 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 })等待，直到可以对目标集群执行写入。
调用 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 })然后，将应用程序工作负载传输到目标集群。
删除目标集群上的元数据数据库。
mongosync 在迁移期间将其元数据存储在一个或多个数据库中。元数据数据库可以命名为以下任何名称：
__mdb_internal_mongosync任何以
__mdb_internal_mongosync_verifier
在迁移成功后，删除任何元数据数据库。
警告
如果您在启动迁移时将 reversible 设置为 true，则在删除元数据数据库后，您将无法撤消迁移。
在 mongosh 中，删除目标集群上的每个元数据数据库：
use <database-name>db.dropDatabase()行为
canWrite 和 COMMITTED
mongosync 允许在 COMMITTED 状态之前的阶段写入目标集群。
您可以在 /progress 报告 canWrite: true 后或状态为 COMMITTED 时写入目标。要学习；了解有关写入阻塞的更多信息，请参阅写入阻塞。如果正在运行mongosync 的多个实例，请仅使用第一个 mongosync进程中的 canWrite 状态。
在初始同步中，mongosync 将源集群上的唯一索引复制为目标集群上的非唯一索引。在提交期间，目标集群上的相关非唯一索引将被设立为 prepareUnique。完成后，/progress 端点开始返回 canWrite: true。具有 prepareUnique 索引的集合会拒绝违反唯一索引约束的新文档。然后，mongosync 将 prepareUnique 索引转换为唯一索引。完成后，mongosync 会将其状态更改为 COMMITTED。
注意
同步大型集合时，将 prepareUnique 索引转换为唯一索引可能会占用大量资源。这可能会导致 /progress 端点返回 canWrite: true 和 mongosync 达到 COMMITTED 状态之间需要很长时间。
虽然应用程序可以在返回 canWrite: true 后发出写入操作，但需要独占锁的操作（例如索引构建）只能在索引转换完成后才能继续。此外，由于竞争资源争用，写入操作在此期间可能会出现延迟增加。