On this page
- Can I perform reads or writes to my destination cluster while
mongosyncrun on its own hardware?
- Should I increase the size of the
oplogin the source cluster?
- Which connection string options does
- Which security and authentication options are supported?
- Can I configure
mongosyncfor 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"?
mongosyncSupport 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
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
false, the behavior
is undefined. To avoid this undefined behavior, you can enable
To check the value of
canWrite, call the progress API endpoint.
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
mongosync applies operations in the
oplog on the source cluster
to the data on the destination cluster. When operations
mongosync has not applied roll off the
on the source cluster, the sync fails and
Starting in version 1.5.0,
mongosync enables Oplog Rollover
Resilience (ORR). With ORR,
mongosync applies changes on the
source cluster to the destination cluster during the initial sync. ORR
increases the resilience of
mongosync to oplog rollover but does not
prevent rollover entirely.
You might exceed the oplog window if you:
Sync from a high write rate source cluster for an extended period.
Pause sync for an extended period.
readConcern is not
mongosync returns an
Invalid URI option, read concern must be majority
writeConcern is not
mongosync returns an
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.
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 binary is stateless. The metadata for restarting is
stored on the destination cluster.
mongosync operation can be resumed if
unavailable during synchronization. When
available again, restart the
mongosync process with the same
mongosync resumes the operation from where it stopped
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
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.