Having some trouble understanding the right approach here.
I have a connection to a mongodb replica set with three members (standard master-slave-slave). Everything is working fine with the connection when the master remains consistent.
pymongo.Connection(['host1:27017','host2:27018','host3:27019']).database_test
For some reason, when the replica set primary steps down, this starts to throw an autoreconnect exception that doesn’t go away even after a new primary is elected.
Now I am aware that this exception needs to be caught and handled, most likely by waiting for the new primary to be elected. The problem I am having seems to be that it doesn’t care at all once the new primary has been chosen. This “master has changed” exception just keeps coming up.
Printing the connection with __dict__ shows all three hosts.
I’ve tried passing the replicaset kwarg to the connection, but this comes up as an unexpected argument.
Is there a reason why this kind of connection wouldn’t just start querying against the new primary?
EDIT:
This same problem is apparently now manifesting on the deployment server. The autoreconnect exception is thrown if the master changes at all and never goes away even after a new primary is elected.
Pymongo is version 2.2 and mongodb version 2.0.2. Changing the manner in which the connection is defined in the pymongo code (mongouri vs. list of hosts) has no effect. The only way to revive the service is to rs.stepDown() the other hosts until the original master is primary once more.
The behavior you describe is a bug. The best possible course of action is to make sure there is a bug logged for it and link to it from your question. Since the question is almost a year old, I am expecting the bug to be closed (check jira.mongodb.org/browse/SERVER-4405 to see if it applies).
If you upgrade to MongoDB 2.2 or later, the problem should go away.