FAQ: Replication and Replica Sets
On this page
- What kinds of replication does MongoDB support?
- Does replication work over the Internet and WAN connections?
- Can MongoDB replicate over a “noisy” connection?
- Why use journaling if replication already provides data redundancy?
- What information do arbiters exchange with the rest of the replica set?
- Is it normal for replica set members to use different amounts of disk space?
- Can I rename a replica set?
MongoDB also supports master-slave replication; however, replica sets are the recommended replication topology. However, if your deployment requires more than 50 nodes, you must use master/slave replication.
Yes, but not without connection failures and the obvious latency.
Members of the set will attempt to reconnect to the other members of the set in response to networking flaps. This does not require administrator intervention. However, if the network connections among the nodes in the replica set are very slow, it might not be possible for the members of the node to keep up with the replication.
Journaling is particularly useful for protection against power failures, especially if your replica set resides in a single data center or power circuit.
Journaling requires some resource overhead for write operations. Journaling has no effect on read performance, however.
Journaling is enabled by default on all 64-bit builds of MongoDB v2.0 and greater.
Arbiters never receive the contents of a collection but do exchange the following data with the rest of the replica set:
- Credentials used to authenticate the arbiter with the replica set. These exchanges are encrypted.
- Replica set configuration data and voting data. This information is not encrypted. Only credential exchanges are encrypted.
If your MongoDB deployment uses TLS/SSL, then all communications between arbiters and the other members of the replica set are secure.
See the documentation for Configure mongod and mongos for TLS/SSL for more information. As with all MongoDB components, run arbiters on secure networks.
The overview of Arbiter Members of Replica Sets.
Factors including: different oplog sizes, different levels of storage fragmentation, and MongoDB’s data file pre-allocation can lead to some variation in storage utilization between nodes. Storage use disparities will be most pronounced when you add members at different times.
You can use the backup and restore procedure described in the Restore a Replica Set from MongoDB Backups tutorial to create a new replica set with the desired name. Downtime may be necessary in order to ensure parity between the original replica set and the new one.