Replication - MongoDB in Action - page 171

and global configuration options. The process of modifying a configuration docu-
ment, incrementing the version number, and passing it as part of the replSetReconfig
can be laborious, so there exist a number of shell helpers to ease the way. To see a list
of them all, enter rs.help() at the shell. You've already seen rs.add() .
Bear in mind that whenever a replica set reconfiguration results in the election of
a new primary node, all client connections will be closed. This is done to ensure that
clients won't attempt to send fire-and-forget writes to a secondary node.
If you're interested in configuring a replica set from one of the drivers, you can see
how by examining the implementation of rs.add() . Enter rs.add (the method with-
out the parentheses) at the shell prompt to see how the method works.
Configuration document options
Until now, we've limited ourselves to the simplest replica set configuration document.
But these documents support several options for both replica set members and for the
replica set as a whole. We'll begin with the member options. You've seen _id , host ,
and arbiterOnly . Here are these plus the rest, in all their gritty detail:
 _id (required) —A unique incrementing integer representing the member's ID .
These _id values begin at 0 and must be incremented by one for each member
added.
 host (required) —A string storing the host name of this member along with an
optional port number. If the port is provided, it should be separated from the
host name by a colon (for example, arete:30000 ). If no port number is speci-
fied, the default port, 27017, will be used.
 arbiterOnly —A Boolean value, true or false , indicating whether this mem-
ber is an arbiter. Arbiters store configuration data only. They're lightweight
members that participate in primary election but not in the replication itself.
 priority —An integer from 0 to 1000 that helps to determine the likelihood
that this node will be elected primary. For both replica set initiation and
failover, the set will attempt to elect as primary the node with the highest prior-
ity, as long as it's up to date.
There are also cases where you might want a node never to be primary (say, a
disaster recovery node residing in a secondary data center). In those cases, set
the priority to 0. Nodes with a priority of 0 will be marked as passive in the
results to the isMaster() command and will never be elected primary.
 votes —All replica set members get one vote by default. The votes setting
allows you to give more than one vote to an individual member.
This option should be used with extreme care, if at all. For one thing, it's dif-
ficult to reason about replica set failover behavior when not all members have
the same number of votes. Moreover, the vast majority of production deploy-
ments will be perfectly well served with one vote per member. So if you do
choose to alter the number of votes for a given member, be sure to think
through and simulate the various failure scenarios very carefully.