Forums

MongoDB/Atlas - No replica set members match selector Primary()

I have a web app hosted on PythonAnywhere that uses Flask and PyMongo 4.6.1. It's been working fine for months and still works fine when I run it on localhost from my development machine. Connection to Atlas also seems good when I run it from PythonAnywhere console, but in the last few days I've been getting critical errors from the PythonAnywhere webserver even though I haven't touched any code that deals with the database connection:

No replica set members match selector Primary(),
Timeout: 30s, Topology Description: topology_type: ReplicaSetNoPrimary, servers: [ 27017) server_type: RSSecondary, rtt: 0.026010908652096987>, (ac-ptjy9js-shard-00-01.emgqo8z.mongodb.net, 27017) server_type: Unknown,
rtt: None, error=AutoReconnect(ac-ptjy9js-shard-00-01.emgqo8z.mongodb.net:27017:
connection pool paused)>, 27017) server_type: RSSecondary, rtt: 0.026285539381206036>]>

This test code works fine in the console or as a regular .py script:

client = MongoClient(
    MONGO_URI,
    connectTimeoutMS=30000,
    socketTimeoutMS=None,
    connect=False,
    maxPoolsize=1,
)
class Test():
    collection = client.HMO['Application Index']
    @classmethod
    def list(cls, query=None, projection=None):
        if query is None:
            query = {}
        if projection is None:
            projection = {}
        return list(cls.collection.find(query, projection))
results = Test.list({'reference': '00631/6-8/P4'})

... but not inside Flask on PythonAnywhere (works fine on development machine and localhost):

@app.route("/test", methods=['GET', 'POST'])
def test():
    response = Test.list({'reference': '00631/6-8/P4'})[0]
    return str(response)

I've subsequently added settings recommended here https://help.pythonanywhere.com/pages/MongoDB/ but still not working. Is there anything else I need to do?

This is a critical error affecting a production system. Many Thanks for any help!

[edit by admin: formatting]

Just to check -- are you using the Flask-MongoDB module that we mention on that help page? Or are you using a "raw" PyMongo connection? Also, have you changed your account type recently -- eg. upgraded from free to paying, or added on any worker processes?

Also, have you checked the allowlist of IPs on Atlas?

Ah, wait, I see that you posted again -- I'll reply there.

Thanks Giles - this post can be deleted now.

Actually while I have your kind attention, I'm kind of curious about your question

have you changed your account type recently -- eg. upgraded from free to paying, or added on any worker processes?

The answer is Yes I think... The code was working for months (maybe over a year) and only started raising errors recently at about the time my client changed his payment details (and may have upgraded/downgraded in the process). Not a great state of affairs if this is what triggered the recent problems?

The only case I can think of where that might cause issues -- and the reason I asked -- would be if you had at some point in the past, after upgrading, asked us to temporarily override the number of worker processes associated with your website to work around some issue or other. The vague (and loosely held!) hypothesis I was wondering about was if this had happened:

  • You upgraded to a paid account, which gave you two worker processes.
  • For some reason you asked us to switch you over to one process while you worked out some kind of issue with your code that made it go wrong with multiple.
  • Everyone forgot that that had happened.
  • You later introduced the MongoDB code; the issue that was discussed in the other thread was one that might not surface with one worker proces.
  • Your client changed their payment details, but instead of doing it directly on the "Account" page, they did it by upgrading or downgrading the account slightly.
  • That would have overridden the earlier change that meant that you only had one worker process
  • ...and then the Mongo issue would have surfaced.

As I said, I don't know if this happened -- unfortunately there's not enough in the way of records or logs to tell -- but it's the kind of thing that might lead to this kind of issue suddenly occuring.

Many thanks for your reply Giles. I don't think we need to pick at this any more but in case you're intellectually curious, think all these steps could have happened EXCEPT the second one (switching to one process). I just don't think it would've occurred to us to ask for that ever.

We did however migrate account from the US server to the EU one some time back... not sure if that's relevant or could have concealed a latent problem for so many months before the payment details change a week or two ago.

Hmm, no, I don't think that the migration could have had that effect -- the number of worker processes would have come across along with all of the other settings.

As you're up and running now, I agree we should probably drop this for now -- but if I have some time later I'll see if I can dig in further and see if I can find anything. I'll post back here if I do!