Database Reference
In-Depth Information
"lastHeartbeatMessage" : "db exception in producer: 10278 dbclient error
communicating with server: [hostname]:27021",
"syncingTo" : "[hostname]:27021"
}
],
"ok" : 1
}
In this example, you ran the
rs.stepDown()
command against the primary server. The output of the
rs.status()
command shows that all members of the replica set are now secondaries. If you run
rs.status()
subsequently, you
should see that another member has stepped up to be primary (assuming one is eligible).
Determining If a Member Is the Primary Server
The
db.isMaster()
command isn't strictly for replica sets. Nevertheless, this command is extremely useful because it
allows an application to test whether a current connection is to a primary server:
>db.isMaster()
{
"setName" : "testset",
"ismaster" : true,
"secondary" : false,
"hosts" : [
"[hostname]:27022",
"[hostname]:27021"
],
"primary" : "[hostname]:27022",
"me" : "[hostname]:27022",
"maxBsonObjectSize" : 16777216,
"maxMessageSizeBytes" : 48000000,
"localTime" : ISODate("2013-06-04T11:22:28.771Z"),
"ok" : 1
}
If you run
isMaster()
against your
testset
replica set cluster at this point, it shows that the server you have run
it against is not a master/primary server (
"ismaster" == false
). If the server instance you run this command against
is a member of a replica set, the command will also return a map of the known server instances in the set, including
the roles of the individual servers in that set.
Configuring the Options for Replica Set Members
The replica set functionality includes a number of options you can use to control the behavior of a replica set's
members. When you run the
rs.initiate(
replSetcfg
)
or
rs.add(
membercfg
)
options, you have to supply a
configuration structure that describes the characteristics of a replica set's members:
{
_id : <setname>,
members: [
{
_id : <ordinal>,
host : <hostname[:port]>,
