Docs Menu
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.

Synchronization sets expireAfterSeconds to the value of MAX_INT on the destination cluster.

Use the collMod command to set expireAfterSeconds to the desired value.

Synchronization replicates hidden indexes as non-hidden.

Use the collMod command to hide any indexes that should be hidden.

If you enable write-blocking, mongosync blocks writes:

  • On the destination cluster during sync.

  • On the source cluster when commit is received.

If synchronization was started with write blocking, disable the Write Block Mode.

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.

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.

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

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

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

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