Docs Home → MongoDB Cluster-to-Cluster Sync

Use `mongosync` for Disaster Recovery

On this page

Unique Indexes

Prepare the Index for Conversion
Resolve Uniqueness Violations
TTL Indexes
Hidden Indexes
Write blocking

Setting up Cluster-to-Cluster Sync to prepare for disaster recovery follows the same procedure as other connections between clusters. Synchronization keeps the destination cluster up to date with the source cluster and ready as a backup. In the event that the source cluster fails or becomes otherwise unavailable, the destination cluster can replace it as the primary cluster.

mongosync temporarily alters some collection characteristics during synchronization. The original values are restored during the commit process. If synchronization ends prematurely, you must manually reset these collection characteristics on the destination cluster before you can use it as the primary cluster.

To prepare the destination cluster to replace the source cluster, make the following changes that mimic the sync finalization process of the commit endpoint.

Change	Description
Unique Indexes	Unique indexes on the source cluster synchronize as non-unique indexes on the destination cluster. Indexes that should be unique must be manually set to unique.
TTL Indexes	Synchronization sets `expireAfterSeconds` to the value of `MAX_INT` on the destination cluster. Use the `collMod` command to set `expireAfterSeconds` to the desired value.
Hidden Indexes	Synchronization replicates hidden indexes as non-hidden. Use the `collMod` command to hide any indexes that should be hidden.
Write Blocking	`mongosync` can disable writes on the destination cluster. If synchronization was started with write blocking, disable the Write Block Mode.

Unique Indexes

mongosync replicates writes in parallel, which can cause transient uniqueness violations on the destination cluster. To avoid these errors, unique indexes are replicated as non-unique. If synchronization ends early, manually resolve any uniqueness violations and convert any non-unique indexes that should be unique into unique indexes.

Prepare the Index for Conversion

For each non-unique index on the destination cluster that should be unique, run collMod with prepareUnique set to true.

After running collMod, the index rejects any new writes that would introduce duplicate keys.

Resolve Uniqueness Violations

There may still be uniqueness conflicts in the index after you run prepareUnique. To find conflicts and convert the index to a unique index, run collMod with unique set to true on each of the non-unique indexes that you want to set as unique.

If the call to collMod succeeds, there are no uniqueness violations on that index and the index is converted to an unique index.

If the call to collMod fails with a CannotConvertIndexToUnique error, correct the uniqueness violations and rerun collMod.

See: Convert an Existing Index

TTL Indexes

During synchronization, expireAfterSeconds is set to MAX_INT for TTL indexes. To reset expireAfterSeconds, use the collMod command to change the expiration value.

Hidden Indexes

During synchronization, hidden indexes are not hidden on the destination cluster. Use the collMod command to hide indexes that should be hidden.

Write blocking

When write blocking is enabled as part of the /start command, mongosync blocks user writes on the destination cluster during replication. If replication ends prematurely, you must manually unblock writing on the destination.

After writing is enabled, you can redirect writes from your client application to the destination cluster.

To enable writes, update setUserWriteBlockMode:

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

← oplog Sizing

Limitations →