Finalize Cutover Process

Verify the status of mongosync.

Call the progress endpoint to determine the status of mongosync before starting the cutover process. Ensure that the mongosync process status indicates the following values:

• canCommit is true.

• lagTimeSeconds is small (near 0).

  If lagTimeSeconds isn't close to 0 when the cutover starts, cutover might take a long time.

• When using the Embedded Verifier check both the verification.source and the verification.destination return documents. The lagTimeSeconds fields in both documents should be near 0 and the phase fields should show "stream hashing".

  If the verifier is not in the stream hashing phase, the cutover process might take a long time.

The following example returns the status of the synchronization process.

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
}

Stop any write operations to the synced collections on the source.

• Wait for all transactions on the source cluster to either commit or abort.

• mongosync enables destination-only write-blocking by default. You can explicitly enable it by starting mongosync with enableUserWriteBlocking set to "destinationOnly". mongosync only blocks writes on the destination and unblocks them right before canWrite is set to true.

• If you start mongosync with enableUserWriteBlocking set to "sourceAndDestination", mongosync blocks all write operations on the destination cluster and unblocks them right before canWrite is set to true. mongosync blocks writes on the source after you call /commit.

• If you start mongosync with enableUserWriteBlocking set to "none", ensure that you disable writes. For example, run the setUserWriteBlockMode command on the source cluster:

  db.adminCommand( {
      setUserWriteBlockMode: 1,
      global: true 
  } )

• If mongosync uses filtered sync, it's not necessary to disable writes to the entire source cluster. However, you must ensure that you stop write operations for the collections that the filter includes.

Send a commit request to mongosync.

If you start multiple mongosync instances for your migration, you must issue a commit request for each mongosync instance.

curl localhost:27182/api/v1/commit -XPOST --data '{ }'

{"success":true}

Wait until you can perform writes on the destination cluster.

Call the progress endpoint to determine if canWrite is true. If canWrite is false, wait until progress shows canWrite is true.

curl -sS localhost:27182/api/v1/progress -XGET | jq ".progress.canWrite"

true

Verify data transfer.

Verify the successful sync of data from the source to the destination cluster.

For more information, see Verify Data Transfer.

If you manually blocked writes on the destination cluster by using setUserWriteBlockMode, enable application writes on the destination cluster.

To enable writes, update setUserWriteBlockMode:

db.adminCommand(
   {
      setUserWriteBlockMode: 1,
      global: false
   }
)

Then, transfer your application workload to the destination cluster.

If you started mongosync with write-blocking by using the enableUserWriteBlocking option on the /start endpoint, you do not need to complete this step.

Call the progress endpoint to determine the status of the mongosync process.

When the mongosync progress response indicates that the mongosync state is COMMITTED, the cutover process is complete.

curl -sS localhost:27182/api/v1/progress -XGET | jq ".progress.state"

"COMMITTED"