Docs Menu

Docs HomeMongoDB Cluster-to-Cluster Sync

Frequently Asked Questions

On this page

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

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.

The oplog in the source cluster must be large enough to track events that happen during the time it takes to complete the initial sync to the destination cluster.

If you anticipate syncing a large data set, or if you plan to pause synchronization for an extended period of time, increase the size of the replica set oplog in the source cluster.

The proper oplog size depends on system hardware, network speed, and other factors including system workload. However, assuming network transfer speeds of 30-50GB per hour, a rough formula to estimate the required oplog size is:

minimumRetentionHours = dataSizeInGB / 30

To estimate the size of oplog needed for initial synchronization, see: oplog Sizing.

To learn more about how to increase the size of the oplog, see: Change the Size of the Oplog.

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.

←  Release Notes for mongosync 1.0
Share Feedback
© 2022 MongoDB, Inc.

About

  • Careers
  • Investor Relations
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2022 MongoDB, Inc.