[confluence] MongoDB > Connecting Drivers to Replica Sets

2 views
Skip to first unread message

nor...@mongodb.onconfluence.com

unread,
Jan 16, 2013, 7:56:00 PM1/16/13
to mongodb...@googlegroups.com

nor...@mongodb.onconfluence.com

unread,
Jan 16, 2013, 7:56:00 PM1/16/13
to mongodb...@googlegroups.com

Page edited by Sam Kleinman


Changes (3)

Ideally a MongoDB driver can connect to a cluster of servers which represent a [replica set|DOCS:Replica Sets], and automatically find the right set member with which to communicate.  Failover should be automatic too.  The general steps are:
# The user, when opening the connection, specifies host\[:port\] for one or more members of the set.  Not all members need be specified \-\- in fact the exact members of the set might change over time.  This list for the connect call is the _seed list_.
# The driver then connects to all servers on the seed list, perhaps in parallel to minimize connect time.  Send an ismaster command to each server.
# When the server is in replSet mode, it will return a _hosts_ field with all members of the set that are potentially eligible to serve data.  The client should cache this information.  Ideally this refreshes too, as the set's config could change over time.
# Choose a server with which to communicate. 
## If ismaster == true, that server is primary for the set.  This server can be used for writes and immediately consistent reads. 
## If secondary == true, that server is not primary, but is available for eventually consistent reads. In this case, you can use the _primary_ field to see which server the master should be. (If primary is not set, you may want to poll other nodes at random; it is conceivable that the member to which we are talking is partitioned from the other members, and thus it cannot determine who is primary on its own. This is unlikely but possible.)
# If an error occurs with the current connection, find the new primary and resume use there.
{redirect:http://docs.mongodb.org/meta-driver/latest/legacy/connect-driver-to-replica-set/}
For example, if we run the ismaster command on a non-primary server, we might get something like:

{code}> db.runCommand("ismaster")
{
"ismaster" : false,
"secondary" : true,
"hosts" : [
"ny1.acme.com",
"ny2.acme.com",
"sf1.acme.com"
],
"passives" : [
"ny3.acme.com",
"sf3.acme.com"
],
"arbiters" : [
"sf2.acme.com",
]
"primary" : "ny2.acme.com",
"ok" : true
}
{code}

There are three servers with priority > 0 (_ny1_, _ny2_, and _sf1_), two passive servers (_ny3_ and _sf3_), and an arbiter (_sf2_). The primary should be _ny2_, but the driver should call ismaster on that server before it assumes it is.

Full Content

Reply all
Reply to author
Forward
0 new messages