Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

ReplicaSetConnection #104

gpitfield opened this Issue Feb 15, 2012 · 14 comments


None yet
6 participants

gpitfield commented Feb 15, 2012

Has anyone tried using pymongo's ReplicaSetConnection instead of just a vanilla Connection? I'm planning to give it a try, didn't see anything about this, but would sure appreciate hearing if anything's been done/tried/abandoned etc. Seems like it might be cleaner than always specifying read and write db's explicitly...


jonashaag commented Feb 15, 2012

I never used ReplicaSetConnections, how are they different from normal Connections (from an API perspective)?


gpitfield commented Feb 16, 2012

Well, that makes two of us :-) From what I can tell, the API is almost identical, but instead of passing a list of nodes you just provide one and the name of the replica set. read_preference, safe, etc are all the same as for Connection, but the nice thing is that ReplicaSetConnection will read from the replicas, whereas vanilla Connection just does everything on the master, and really only uses the replicas if there's a failure and one becomes the master.

There are clearly cases where you'd want to explicitly designate the master to be read from (e.g. if you're planning to save that object back), but oftentimes it doesn't matter. In my case, I'll end up specifying several different DBs, but I want the default to work like this.

My thought was simply to allow for a keyword "REPLICA_SET_NAME" to be provided, and if that happened we'd just use a ReplicaSetConnection. I think it's only a couple of lines of code to enable it - fingers crossed.

Any thoughts before I embark?


jonashaag commented Feb 17, 2012

If I understand things correctly, the default Connection already handles replica sets (even has a replicaSet parameter) but ReplicaSetConnection adds a bunch of features. If they're of relevance for use with Django, I'm all for your proposal.


gpitfield commented Feb 17, 2012

That pretty much summarizes my understanding. I'll give it a go and see where I get...

Are there any updates regarding this issue? The changes are supposed to be trivial, indeed.


jonashaag commented Jul 3, 2012

The most reliable way to get them is to just code them up yourself and send a pull request :)


gpitfield commented Jul 3, 2012

I've actually got a branch that does this. However, it lacks tests. I'm not sure how the test infrastructure needs to be set up to test against a ReplicaSet as opposed to a regular mongo instance. Any advice so I can put the tests in and send a pull request?


jonashaag commented Jul 3, 2012

You could mock the functions/classes to see they're actually called similar to what we do here

I've tried gpitfield's branch, though connection was made with ReplicaSetConnection and I've specified read_preference=SECONDARY , all queries are stilled routed to primary

I found collection = CollectionDebugWrapper(collection, self.alias) would made all request routed to primary even though ReplicaSetConnection was enabled. Anybody know why?


gpitfield commented Aug 11, 2012

@bigeagle not sure I understand your second comment. Re: secondary read_preference, we're using that in production so it definitely does work, at least on whatever branch we're using (I'd have to check that this one is current). If you specify SECONDARY and the secondary isn't available, it will route it to the primary instead. If you want to force secondary, I think you need SECONDARY_ONLY which will fail if no secondary is available. So you might want to try that to see if you can get any further insight.


gpitfield commented Aug 11, 2012

@bigeagle also make sure you're using the develop branch, which is the most current.

@gpitfield I've solved that. I have DEBUG=True in settings'py, than mongodb_engine would return a debug wrapped db cursor without read_preference option. I also made a branch to handle this.


markunsworth commented Jun 16, 2015

This is now resolved. Should be closed

@aburgel aburgel closed this Jun 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment