Databases Reference
In-Depth Information
Once the slave's log shows that it has finished syncing, the document will be updated
to reflect this:
> db.sources.find()
{
"_id" : ObjectId("4c1650c2d26b84cc1a31781f"),
"host" : "localhost:27017",
"source" : "main",
"syncedTo" : {
"t" : 1276530906000,
"i" : 1
},
"localLogTs" : {
"t" : 0,
"i" : 0
},
"dbsNextPass" : {
"test_db" : true
}
}
Now, suppose we are going into production and we want to change the slave's con-
figuration such that it slaves off of
prod.example.com
. We can change the source for the
slave using
insert
and
remove
:
> db.sources.insert({"host" : "prod.example.com:27017"})
> db.sources.remove({"host" : "localhost:27017"})
As you can see,
sources
can be manipulated like a normal collection and provides a
great deal of flexibility for managing slaves.
If you slave off of two different masters with the same collections,
MongoDB will attempt to merge them, but correctly doing so is not
guaranteed. If you are using a single slave with multiple different mas-
ters, it is best to make sure the masters use different namespaces.
Replica Sets
A
replica set
is basically a master-slave cluster with automatic failover. The biggest
difference between a master-slave cluster and a replica set is that a replica set does not
have a single master: one is elected by the cluster and may change to another node if
the current master goes down. However, they look very similar: a replica set always has
a single master node (called a
primary
) and one or more slaves (called
secondaries
). See
Figures
9-3
,
9-4
, and
9-5
.
The nice thing about replica sets is how automatic everything is. First, the set itself does
a lot of the administration for you, promoting slaves automatically and making sure
you won't run into inconsistencies. For a developer, they are easy to use: you specify a
few servers in a set, and the driver will automatically figure out all of the servers in the
set and handle failover if the current master dies.
