Database Reference
In-Depth Information
Replication
Replication is an important subject for MongoDB. In early versions of the
database, the claim was that single-machine durability could not be trusted,
and a lot of emphasis was placed on the need to use replicas to ensure
datadurability.Version2.0andlatersupportjournalingwritesthatimprove
single-machine durability, but multi-machine replication is still the
preferred strategy for MongoDB durability.
To handle replication, MongoDB uses a system called a Replica Set. Like
Kafka's in-sync replicas, this approach is still essentially a master-slave
architecture, but the master is elected by a quorum of set members rather
than explicitly assigned. The current master is called the Primary, and it
keeps track of all of the other members—called Secondaries—via a heartbeat
mechanism. All writes are conducted against the Primary, but reads can be
conducted against any of the servers in the Replica Set.
NOTE
Replication in MongoDB is asynchronous. Reads from the Primary
always return the most recent data, but a read from a Secondary may
not have received the most recent data yet. To further complicate the
situation, MongoDB's developers allow a replication delay to be
explicitly set as well. This creates replicas that are intentionally lagging
the Primary by a specified amount. This can be useful for certain types
of disaster recovery scenarios. To prevent clients from inadvertently
reading from these lagging replicas, MongoDB also includes the ability
to hide replicas in the set, making them unavailable to clients.
In addition to maintaining heartbeat connections with the Primary,
Secondaries maintain a heartbeat with each other. If contact with the
Primary is lost for more than 10 seconds, the Secondaries elect a new
Primary from among themselves, allowing for mostly automatic failover.
This may result in a rollback of data that was written to the Primary before
it lost contact with the rest of the cluster.
