Nothing db-related in our back end has changed except updating the mongodb nodejs driver to 6.x.x (was not the culprit).
Local scripts can still hit the local dev env db fine, and Compass can still connect to staging/prod fine. So i am at a loss at what all of a sudden has changed to cause timeout issues when attempting to connect to Atlas via the mongodb MongoClient.
The TL;DR is this is a DNS query timing out so the seed list of server the MongoClient needs to connect to isn’t being retrieved. You can work around this by just using the legacy mongodb:// connection string for your cluster instead of the mongodb+srv:// variation.
Hey, Alex. Thanks for weighing in! That was an interesting suggestion, but now I am getting ENOTFOUND errors. I’m just now looking into this new development, so any further suggestions would be appreciated…
Update; the planets must have all moved back out of alignment, it seems, because today my scripts can successfully connect using the same mongodb+srv string that they’ve been using previously. SMH.
Thanks for that link, it’s an interesting read, and i’ll make sure to keep it handy for future reference.
These DNS failures tend to be transient which is why I proposed DRIVERS-2757 to try to automatically retry on these types of failures. This is something we hope to tackle after doing some additional research to make sure we’re solving the right problem in these situations
Two days ago we had to move our web app and the mongo atlas cluster from east 2 to east, due to the ongoing azure outage.
We started getting the server lookup errors every few minutes. The application works fine and there are no other errors besides this, always logged by “a monitor thread”.
We use standard java MongoDb driver.
Any advice on what to do? We have only two ideas so far
wait it out and move back to us east 2
Try migrate data to a completely new cluster with new endpoints in hopes it resolves some unclear DNS issues.
