Database Reference
In-Depth Information
config.members.push({_id: 0, host: 'arete:40000'})
config.members.push({_id: 1, host: 'arete:40001'})
config.members.push({_id: 2, host: 'arete:40002', arbiterOnly: true})
Your configuration document should now look like this:
> config
{
"_id" : "myapp",
"members" : [
{
"_id" : 0,
"host" : "arete:40000"
},
{
"_id" : 1,
"host" : "arete:40001"
},
{
"_id" : 2,
"host" : "arete:40002",
"arbiterOnly" : true
}
]
}
You can then pass the document as the first argument to
rs.initiate()
to initiate the
replica set.
Technically, the document consists of an
_id
containing the name of the replica
set, an array specifying between 3 and 12
members
, and an optional subdocument for
specifying certain global settings. This sample replica set uses the minimum required
configuration parameters, plus the optional
arbiterOnly
setting.
The document requires an
_id
that matches the replica set's name. The initiation
command will verify that each member node has been started with the
--replSet
option with that name. Each replica set
member
requires an
_id
consisting of increas-
ing integers starting from 0. Members also require a
host
field with a host name and
optional port.
Here you initiate the replica set using the
rs.initiate()
method. This is a simple
wrapper for the
replSetInitiate
command. Thus you could've started the replica set
like so:
db.runCommand({replSetInitiate: config});
config
is simply a variable holding your configuration document. Once initiated,
each set member stores a copy of this configuration document in the
local
database's
system.replset
collection. If you query the collection, you'll see that the document
now has a version number. Whenever you modify the replica set's configuration, you
must also increment this version number.
To modify a replica set's configuration, there's a separate command,
replSet-
Reconfig
, which takes a new configuration document. The new document can specify
the addition or removal of set members along with alterations to both member-specific
