Getting "not master and slaveOk=false" from mongo after 1.7 upgrade


Since I’m developing on Windows 10 and MDG hasn’t released a 1.6.1.x patch version to fix the Windows symlink problem, I upgraded to 1.7 rc11 (the latest release candidate). After adding a couple of missing packages and rebuilding my db everything seemed to work ok. But now every few hours mongo exits with code 3 (not master and slaveOk=false) and restarts. According to the Mongo docs the error seems to relate to trying to read from a specific mongo replica set rather than from the master, but I have no replica sets. I can’t tell if this is related to Meteor 1.7 or the 3.6 version of Mongo. Anyone else seeing this or have a suggestion as to how to fix?


If you are running meteor in development you do have replica sets, as Meteor sets these up for you, in order that oplog tailing can work.

However, as to your actual problem, I’ve not seen this. I’ll try it myself in Windows to see if I can replicate it.


I recently had this issue with Meteor 1.6 in production. Oddly, it broke the entire data layer, and was fixed by a manual restart.


Ah, knowing that I do have replica sets makes a bit more sense. The server stack trace that follows the crash occasional is ECONNREFUSED, which makes sense since Mongo may not have come up fully when the query was being made, but more often than not I get some flavor of this:

I20180528-19:58:13.001(-7)? Exception while polling query {"collectionName":"MeteorToys.Impersonate","selector":{},"options":{"transform":null,"limit":15}} { MongoError: not master and slaveOk=false

Maybe MeteorToys isn’t compatible with 1.7? I’ll try removing it and see if the crashes stop (meteortoys is included by msavin:mongol, which I can probably live without.)


@robfallows, I doubt you could reproduce it. It appears to be “random” as my app ran fine
overnight, but crashed 3 times yesterday.

@msavin, the crashes don’t seem to have an effect on the functioning of the app once Mongo restarts, but that may simply be that this is in dev mode and there is no load on the app. Manual restarts don’t make any difference.


It’s hard to find in the meteor source, but if they’re using Mongo 3.6, they’re going to discover that it has a colossal number of problems on Windows, including almost certainly yours.

To address your issues, I’d recommend installing MongoDB 3.6 series from an MSI and using MONGO_URL to connect to a locally-running, administrative privileges elevated mongod started as a replica set.


@doctorpangloss, 1.7-rc11 uses Mongo 3.6.4. I’m not having any problems with Mongo other than this specific error. I removed the mongol package (which removes meteortoys package) and have made it to the 24 hour mark with no crashes. Once I hit the 48 hour mark tomorrow, I’m going to put mongol back in and see what happens. But at this point, I’m leaning toward a compatibility problem with meteortoys and the meteor 1.7 stack. The meteortoys website only claims 1.5 compatibility, so I wouldn’t be surprised if there is a problem with 1.7 given all of the changes since 1.5.


Well, the problem is not related to MeteorToys.:cry: Windows, as is it’s wont, decided to restart itself, and the problem started happening again. Sometimes node.js provides a stack trace, sometimes node doesn’t even seem to notice. The problem may be a Windows 10 MongoDB issue, but my Python apps that also access the meteor DB don’t seem to be experiencing the problem. Any suggestions as to how to debug the issue? I’m happy to add whatever monitoring or test code anyone cares to suggest. I’m loath to push the meteor 1.7rc to my Linux server since my app there is being used by my testers. At this point, I’m going to ignore the problem and wait to push my app to Linux until 1.7 is actually released.

I just noticed that Mongo exited twice while I was typing this. Since no one was accessing my app, the exits/crashes seem to happen at random intervals.


I also faced this problem today when running meteor test. Here’s the full output I got:

[[[[[ Tests ]]]]]

=> Started proxy.
=> A patch (Meteor for your current release is available!
   Update this project now with 'meteor update --patch'.
=> Started MongoDB.

MongoError: not master and slaveOk=false
    at queryCallback (/Users/simon/.meteor/packages/npm-mongo/.3.0.7.iikbq7.drrf++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/cursor.js:244:25)
    at /Users/simon/.meteor/packages/npm-mongo/.3.0.7.iikbq7.drrf++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)
=> Started your app.

=> App running at: http://localhost:3100/
npm ERR! Test failed.  See above for more details.

I’m using Meteor and (as you see) meteor also spins up the database.

Any other info I can give you? I also had this once on our hosted development environment but I have not seen it otherwise. It seems to be occasional, so I guess it’s very hard to reproduce. I would give a hint on a race-condition when spinning up the replica set - could this be true?


Most likely, Meteor Toys collections are showing up because they load the rest of your code. IIRC, the code in packages executes prior to the code in ./server


Removing MeteorToys and mongol had no effect on the problem. I still see the error several times per day. Other than being an annoyance, the error doesn’t seem to cause any user visible problems.


Any luck resolving this one? It’s currently killing our CI despite several hacky workarounds :frowning:


No luck resolving this. I stripped out as much code (both mine and 3rd party) from my app while still leaving it able to query the database and the problem remained. Stopping the Python apps that also access the MongoDB instance also did nothing. I was hoping that someone smarter than me (or at least with more free time) would figure this out.

One thing that I didn’t try (since it wasn’t available yet) is to try against a MongoDB 4 server. Another possible way to find the issue would be to roll my Meteor back to 1.6 and compare network traces against 1.7.

= Ron