0

we needed to duplicate a legacy meteorJS app recently, onto a new server and a new database. So we cloned the server, created a new database and pointed the cloned server to the new database.

The meteorJS app works, everything appears fine.

However we noticed that the logs is showing error like MongoError: no primary server available, everytime when restarting:

2024-02-01T06:37:06.151478+00:00 heroku[web.1]: Restarting
2024-02-01T06:37:06.217824+00:00 heroku[web.1]: State changed from up to starting
2024-02-01T06:37:06.969254+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2024-02-01T06:37:07.074219+00:00 heroku[web.1]: Process exited with status 143
2024-02-01T06:37:45.658856+00:00 heroku[web.1]: Starting process with command `.meteor/heroku_build/bin/node $NODEJS_PARAMS .meteor/heroku_build/app/main.js`
2024-02-01T06:38:00.149936+00:00 app[web.1]: Got exception while polling query MongoError: no primary server available
2024-02-01T06:38:00.149991+00:00 app[web.1]:     at ReplSetState.pickServer (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/core/topologies/replset_state.js:780:12)
2024-02-01T06:38:00.149991+00:00 app[web.1]:     at Timeout._selectServer [as _onTimeout] (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/core/topologies/replset.js:1142:43)
2024-02-01T06:38:00.149992+00:00 app[web.1]:     at listOnTimeout (internal/timers.js:549:17)
2024-02-01T06:38:00.149992+00:00 app[web.1]:     at processTimers (internal/timers.js:492:7)
2024-02-01T06:38:00.149993+00:00 app[web.1]:  => awaited here:
2024-02-01T06:38:00.149993+00:00 app[web.1]:     at Function.Promise.await (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:56:12)
2024-02-01T06:38:00.149994+00:00 app[web.1]:     at packages/mongo/mongo_driver.js:1073:14
2024-02-01T06:38:00.149994+00:00 app[web.1]:     at /app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/fiber_pool.js:43:40
2024-02-01T06:38:00.149994+00:00 app[web.1]:  => awaited here:
2024-02-01T06:38:00.149995+00:00 app[web.1]:     at Promise.await (/app/.meteor/heroku_build/app/programs/server/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:60:12)
2024-02-01T06:38:00.149995+00:00 app[web.1]:     at SynchronousCursor._nextObject (packages/mongo/mongo_driver.js:1122:38)
2024-02-01T06:38:00.149995+00:00 app[web.1]:     at SynchronousCursor.forEach (packages/mongo/mongo_driver.js:1136:22)
2024-02-01T06:38:00.149995+00:00 app[web.1]:     at Cursor.<computed> [as forEach] (packages/mongo/mongo_driver.js:918:44)
2024-02-01T06:38:00.149996+00:00 app[web.1]:     at OplogObserveDriver._runQuery (packages/mongo/oplog_observe_driver.js:729:16)
2024-02-01T06:38:00.149996+00:00 app[web.1]:     at OplogObserveDriver._runInitialQuery (packages/mongo/oplog_observe_driver.js:658:10)
2024-02-01T06:38:00.149996+00:00 app[web.1]:     at packages/mongo/oplog_observe_driver.js:191:10
2024-02-01T06:38:00.149996+00:00 app[web.1]:     at packages/mongo/oplog_observe_driver.js:15:9
2024-02-01T06:38:00.149997+00:00 app[web.1]:     at Meteor.EnvironmentVariable.EVp.withValue (packages/meteor.js:1234:12)
2024-02-01T06:38:00.149997+00:00 app[web.1]:     at packages/meteor.js:550:25
2024-02-01T06:38:00.149997+00:00 app[web.1]:     at runWithEnvironment (packages/meteor.js:1286:24) {
2024-02-01T06:38:00.149997+00:00 app[web.1]:   name: 'MongoError',
2024-02-01T06:38:00.149997+00:00 app[web.1]:   [Symbol(mongoErrorContextSymbol)]: {}
2024-02-01T06:38:00.149998+00:00 app[web.1]: }

So it appears that oplogs may not be working on the new server. Since the server shares the exact same codebase, we thought it must be something related to the new database. But we couldn't be sure what was wrong as we were not the one who configured the oplog in the legacy original server.

Both the old and new servers has the following environment variables configured:

OLD SERVER
MONGO_OPLOG_URL
mongodb+srv://user:[email protected]/local
MONGO_URL
mongodb+srv://user:[email protected]/database_name

NEW SERVER
MONGO_OPLOG_URL
mongodb+srv://user:[email protected]/local
MONGO_URL
mongodb+srv://user:[email protected]/databse_name

Also checked the networking IP address restrictions, which has no restrict so we can rule out the possibilities that the new database has IP restrictions.

So what could be the problem in the new database that causes this MongoError: no primary server available in oplog operations?

No much changes in any versions as we try not to break the legacy app:

OLD APP

MongoDB 4.4.28
Meteor 1.10.2
[email protected]

NEW APP

MongoDB 5.0.24
Meteor 1.10.2
[email protected]

EDIT I have just tried to upgrade the Meteor from 1.10.2 to 2.6 but I am facing new issues like these:

Meteor 1.10.2 + MongoDB 5.0 + oplog = fast but update failed
Meteor 1.10.2 + MongoDB 5.0 + no oplog = fast and update success 
Meteor 2.6 + MongoDB 5.0 + oplog = extreme slowness. not usable
Meteor 2.6 + MongoDB 5.0 + no oplog = app crash. boot timed out

Any idea how to investigate on this?

Improve this question
6
  • Is version of mongodb remain the same? Did you upgrade any dependencies from npm during migration? Please add versions of the db, meteor, mongo driver. No primary is a normal exception during primary election. It should be expected to happen at any time, an retries should be handled on application level. Can you provide any details of "oplog operations" that reveal the error? Commented Feb 1, 2024 at 9:13
  • @AlexBlex Hi Alex thanks for the confirmation that No primary is a normal exception. No upgrade of any dependencies to avoid breaking the legacy app. I have added the versions into the original question. As the Meteor oplog is supposed to speed up the site it is unclear if it is even working at the moment. Commented Feb 2, 2024 at 4:27
  • hmm, if you cannot confirm it's broken, how do you confirm it is fixed? I will ask again, what are the opplog operations that cause "MongoError: no primary server available" errors? Commented Feb 2, 2024 at 8:44
  • The error messages are not always accurate. Sometimes they mask other errors, or represent best guess of the cause. Keep in mind that oplog is an internal collection used to maintain consistency of the replica set. Mongo can change format of oplog documents without notice, and you had major version upgrade on db side. Commented Feb 2, 2024 at 8:49
  • 1
    Just realised it's in t logs you posted. As said before the no-primary is nothing unusual and happens every time a primary steps down. If it happens often I'd check mongodb logs to do RCA and fix. Otherwise people seem to confirm that meteor handles it and recovers when a new primary steps in: github.com/meteor/meteor/pull/10861#issuecomment-592807375 Commented Feb 2, 2024 at 12:35

1 Answer 1

Reset to default
1

Meteor 1.10.2 doesn’t support MongoDB 5. You need to downgrade MongoDB server to version 4 or upgrade Meteor to 2.6. You can check the migration guide where MongoDB upgrade was explained on https://guide.meteor.com/2.6-migration.html.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Hi Frederico, noted. I tried to upgrade to Meteor 2.6 but all queries appears to be extremely slow and app is not usable. I added my observations to the question. Any idea how should I investigate further?
MongoDB 5 has significantly changed the oplog API. In version 2.6, we needed to develop a converter to adapt to these changes. You can upgrade to 2.6.1 for some fixes, but it's preferable to upgrade to 2.8 (specifically 2.8.2 with patches), as improvements have been made to the oplog converter, as seen in this GitHub pull request: github.com/meteor/meteor/pull/12116.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.