Fetching contributors…
Cannot retrieve contributors at this time
122 lines (84 sloc) 4.36 KB
FAQ: Replication and Replica Sets
.. default-domain:: mongodb
.. contents:: On this page
:backlinks: none
:depth: 1
:class: singlecol
This document answers common questions about replication in MongoDB.
See also the :doc:`/replication` section in the manual, which provides
an :doc:`overview of replication </replication>`, including details on:
- :doc:`/core/replica-set-members`
- :doc:`/core/replica-set-architectures`
- :doc:`/core/replica-set-elections`
What kinds of replication does MongoDB support?
MongoDB supports :doc:`replica sets </replication>`, which can have up
to :ref:`50 nodes <3.0-replica-sets-max-members>`.
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.
Does replication work over the Internet and WAN connections?
For example, a deployment may maintain a :term:`primary` and :term:`secondary`
in an East-coast data center along with a :term:`secondary` member for disaster
recovery in a West-coast data center.
.. seealso:: :doc:`/tutorial/deploy-geographically-distributed-replica-set`
Can MongoDB replicate over a "noisy" connection?
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.
.. seealso:: :doc:`/core/replica-set-elections`
Why use journaling if replication already provides data redundancy?
:term:`Journaling <journal>` facilitates faster crash recovery.
Prior to journaling, crashes often required :dbcommand:`database repairs <repairDatabase>`
or full data resync. Both were slow, and the first was unreliable.
Journaling is particularly useful for protection
against power failures, especially if your replica set resides in a single data
center or power circuit.
When a :term:`replica set` runs with journaling, you can safely restart
:program:`mongod` instances without additional intervention.
.. note::
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.
What information do arbiters exchange with the rest of the replica set?
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 :doc:`/tutorial/configure-ssl` for more
information. As with all MongoDB components, run arbiters on secure
.. see:: The overview of
:ref:`Arbiter Members of Replica Sets
Is it normal for replica set members to use different amounts of disk space?
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
Can I rename a replica set?
You can use the backup and restore procedure described in the
:doc:`/tutorial/restore-replica-set-from-backup` 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.