Ruby Replication Set Node Discovery

37 views
Skip to first unread message

karl

unread,
Aug 9, 2011, 7:28:33 AM8/9/11
to mongo...@googlegroups.com
I'm wondering why the Ruby driver (and possibly others) does node-discovery the way it does. Specifically, it uses the seed node[s] which is provided and uses the ismaster command to discover new nodes. It then uses the ismaster command on any discovered nodes and repeats the process until no new node is discovered.

Why not just issue a replSetGetStatus to a seed node and use that to build up a view of the replica set? The documentation states that getStatus returns the status "from this node's point of view". What does that mean? Under what condition is the node's view of the set not the actual view (and does it matter when we are trying to auto-discover from a driver)?

Along those lines, why does ismaster return so much more data than just true/false?  There seems to be overlap between the two commands, and isMaster seems to be doing more than it really should.

Anyways, I'm just curious if relying exclusive on replSetGetStatus from a single node would result in the same auto-discovery? I'm interested in fixing some limitation of Ruby's replica set handling, and one thing I'd like to do is clean up some of the code.

Karl

Kristina Chodorow

unread,
Aug 9, 2011, 9:07:19 AM8/9/11
to mongo...@googlegroups.com
The main reason is that replSetGetStatus is an admin-only command.  Thus, if someone is using authentication, they couldn't get information about the set.  Also, replSetGetStatus returns all of the nodes, even ones that are hidden (specifically should not be read from).

isMaster has mutated into the "(almost) everything a driver needs to know about a server on making a connection," so it'll probably continue to sprout fields.  It's kind of annoying, but difficult to move to a "clientInfo" command or something at this point, as all of the drivers would have to change and continue supporting isMaster.

Relying on one or two isMaster calls should be sufficient, unless certain nodes can't see the primary.  (Optimally: call isMaster on seed1, find the primary field, call isMaster on the primary just to be sure, done.)


--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-dev/-/IzYPyZYhs3YJ.
To post to this group, send email to mongo...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-dev?hl=en.

karl

unread,
Aug 9, 2011, 9:26:39 AM8/9/11
to mongo...@googlegroups.com
Thanks. Makes sense. However, I'm running 1.8.1 and I don't see a way to get the master from isMaster. Slaves and the master are merged into the "hosts"...this means that, at worst case, you need to keep going until you call isMaster on the actual master (and thus get ismaster: true).

From the sounds of it, you seem to be indicating that isMaster: 1 returns the master in a separate entry than the slaves. Is this a recent change,something upcoming, or are you mistaken? :)

Karl

Brendan W. McAdams

unread,
Aug 9, 2011, 9:28:56 AM8/9/11
to mongo...@googlegroups.com

On any server that isn't the primary, (eg isMaster is false)  an extra field is included,  "primary", with the address of the replica set primary.

> --
> You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-dev/-/ynrJhlKikT8J.

karl

unread,
Aug 9, 2011, 9:31:40 AM8/9/11
to mongo...@googlegroups.com
duh..of course I connected to the master to double check the behavior. Makes a lot more sense, thanks.

Karl

Kristina Chodorow

unread,
Aug 9, 2011, 9:50:53 AM8/9/11
to mongo...@googlegroups.com
FYI, in 2.0, the "primary" field will be there on the primary, too.


On Tue, Aug 9, 2011 at 9:31 AM, karl <karls...@gmail.com> wrote:
duh..of course I connected to the master to double check the behavior. Makes a lot more sense, thanks.

Karl

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/mongodb-dev/-/F_lvcgWDBq8J.

Kyle Banker

unread,
Aug 9, 2011, 10:34:41 AM8/9/11
to mongo...@googlegroups.com
One more note:

We need to call isMaster for each node to ensure that actual state of
the state of the system, is consistent with the state provided by the
first call to isMaster.

Reply all
Reply to author
Forward
0 new messages