Docs Menu
Docs Home
MongoDB Cluster-to-Cluster Sync

Frequently Asked Questions

On this page

  • Can I perform reads or writes to my destination cluster while mongosync is syncing?
  • Can mongosync run on its own hardware?
  • Should I increase the size of the oplog in the source cluster?
  • Which connection string options does mongosync allow?
  • Which security and authentication options are supported?
  • Can I configure mongosync for high availability?
  • Can the source or destination be a replica set with arbiters?
  • What if I see a Slow Operation Warning?
  • Should I stop a migration if the logs contain the word "error" or "failure"?
  • Does mongosync Support TTL Indexes?

This page provides answers to some frequently asked questions we have encountered. If you have additional questions please contact MongoDB Support.

You can perform reads during synchronization if canCommit is true. However, the data that you read is eventually consistent, meaning that you might not always read the latest writes.

During an ongoing sync, you can write to any non-synced namespaces in the destination cluster as long as the source cluster doesn’t include a namespace with the same name. If you write to a synced namespace before issuing a commit and while canWrite is false, the behavior is undefined. To avoid this undefined behavior, you can enable write blocking.

To check the value of canCommit or canWrite, call the progress API endpoint.

Yes, mongosync can run on its own hardware. mongosync does not have to run on the servers that host your MongoDB instances. When mongosync runs on its own hardware, it can use an operating system (OS) that is different than the OS on the source or destination clusters.

mongosync applies operations in the oplog on the source cluster to the data on the destination cluster. When operations that mongosync has not applied roll off the oplog on the source cluster, the sync fails and mongosync exits.


mongosync does not replicate applyOps operations made on the source cluster during sync to the destination cluster.

During the initial sync, mongosync may apply operations at a slower rate due to copying documents concurrently. After the initial sync, mongosync applies changes faster and is more likely to maintain a position in the oplog that is close to the real-time writes occurring on the source cluster.

If you anticipate syncing a large data set, or if you plan to pause synchronization for an extended period of time, you might exceed the oplog window. Use the oplogSizeMB setting to increase the size of the oplog on the source cluster.

mongosync requires readConcern: "majority" and writeConcern: "majority".

If the readConcern is not majority, mongosync returns an error:

Invalid URI option, read concern must be majority

If the writeConcern is not majority, mongosync returns an error:

Invalid URI option, write concern must be majority

mongosync accepts all other connection string options.

mongosync uses a standard MongoDB connection string to connect to the source and destination clusters.

LDAP and X509 are supported. For available authentication options, see Authentication.

There is no automatic failover built into mongosync. However you can write a script or use your operating system's process managers, systemd for example, to restart the mongosync process.

The mongosync binary is stateless. The metadata for restarting is stored on the destination cluster.

A mongosync operation can be resumed if mongosync becomes unavailable during synchronization. When mongosync becomes available again, restart the mongosync process with the same parameters. mongosync resumes the operation from where it stopped when mongosync became unavailable.

Yes, the replica set can have arbiters. The source replica set must have more than 2 non-arbiter nodes and you must sync from a non-arbiter node. Use the source cluster's connection string to specify a read preference for a non-arbiter, data-bearing node.

Slow operation warnings can occur during the initial sync or the application of a change event when there is a slow read operation on the source cluster or a slow write operation on the destination cluster. The warning may indicate network congestion or resource strain on the source or destination cluster.

While these warnings do not indicate failures in themselves, slow operations can cause operation timeout errors in mongosync and migration failures.

If you see slow operation warnings, check CPU, memory, and network usage on the source and destination clusters. If the clusters are underprovisioned for your needs, consider upgrading the cluster hardware.

No, logs that contain the word "error" or "failure" show non-fatal errors and do not signal that you need to stop mongosync early. These logs do not indicate that mongosync is failing or corrupting data. If a fatal error occurs, mongosync stops the sync and writes a fatal log entry.

Cluster-to-Cluster Sync supports syncing TTL Indexes from the source to the destination cluster.

← Release Notes for mongosync 0.9