Database Reference
In-Depth Information
running in production. Knowing from experience how your replica set will behave in
these failures cases will secure some peace of mind and give you the wherewithal to
calmly deal with emergencies as they occur.
8.3
Master-slave replication
Master-slave replication is the original replication paradigm in MongoDB. This flavor
of replication is easy to configure and has the advantage of supporting any number of
slave nodes. But master-slave replication is no longer recommended for production
deployments. There are a couple reasons for this. First, failover is completely manual.
If the master node fails, then an administrator must shut down a slave and restart it as
a master node. Then the application must be reconfigured to point to the new master.
Second, recovery is difficult. Because the oplog exists only on the master node, a fail-
ure requires that a new oplog be created on the new master. This means that any
other existing nodes will need to resync from the new master in the event of a failure.
In short, there are few compelling reasons to use master-slave replication. Replica
sets are the way forward, and they're the flavor of replication you should use.
8.4
Drivers and replication
If you're building an application and using MongoDB's replication, then you need to
know about three application-specific topics. The first concerns connections and
failover. Next comes write concern, which allows you to decide to what degree a given
write should be replicated before the application continues. The final topic, read scal-
ing, allows an application to distribute reads across replicas. I'll discuss these topics
one by one.
8.4.1
Connections and failover
The MongoDB drivers present a relatively uniform interface for connecting to replica
sets.
S INGLE - NODE CONNECTIONS
You'll always have the option of connecting to a single node in a replica set. There's
no difference between connecting to a node designated as a replica set primary and
connecting to one of the vanilla standalone nodes we've used for the examples
throughout the topic. In both cases, the driver will initiate a TCP socket connection
and then run the isMaster command. This command then returns a document like
the following:
{ "ismaster" : true, "maxBsonObjectSize" : 16777216, "ok" : 1 }
What's most important to the driver is that the isMaster field be set to true , which
indicates that the given node is either a standalone, a master running master-slave rep-
lication, or a replica set primary. 11 In all of these cases, the node can be written to, and
the user of the driver can perform any CRUD operation.
11
The isMaster command also returns a value for the maximum BSON object size for this version of the
server. The drivers then validate that all BSON objects are within this limit prior to inserting them.
Search WWH ::




Custom Search