Database Reference
In-Depth Information
"name" : "arete:40002",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 5,
"optime" : {
"t" : 0,
"i" : 0
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2011-09-27T22:09:03Z"),
"pingMs" : 0
}
],
"ok" : 1
}
Unless your MongoDB database contains a lot of data, the replica set should come
online within 30 seconds. During this time, the
stateStr
field of each node should
transition from
RECOVERING
to
PRIMARY
,
SECONDARY
, or
ARBITER
.
Now even if the replica set status claims that replication is working, you may want
to see some empirical evidence of this. So go ahead and connect to the primary node
with the shell and insert a document:
$ mongo arete:40000
> use bookstore
switched to db bookstore
> db.books.insert({title: "Oliver Twist"})
> show dbs
admin (empty)
bookstore 0.203125GB
local 0.203125GB
Initial replication should occur almost immediately. In another terminal window,
open a new shell instance, but this time point it to the secondary node. Query for the
document just inserted; it should have arrived:
$ mongo arete:40001
> show dbs
admin (empty)
bookstore 0.203125GB
local 0.203125GB
> use bookstore switched to db bookstore
> db.books.find()
{ "_id" : ObjectId("4d42ebf28e3c0c32c06bdf20"), "title" : "Oliver Twist" }
If replication is indeed working as displayed here, then you've successfully configured
your replica set.
It should be satisfying to see replication in action, but perhaps more interesting is
automated failover. Let's test that now. It's always tricky to simulate a network parti-
tion, so we'll go the easy route and just kill a node. You could kill the secondary, but
that merely stops replication, with the remaining nodes maintaining their current sta-
tus. If you want to see a change of system state, you need to kill the primary. A
