Fixing Mongo Error 62 - Best Practices for App in Production?

help
1

I’m updating from Meteor 2.10 to 2.12, and getting the message on my dev system:

Unexpected mongo exit code 62. Restarting.

I can follow the steps here to migrate my local dev system to Mongo 6.

What are the best practices for updating my app running in production on Galaxy? I’m guessing:

  • Log into MongoDB, where my mongo db is hosted, and make sure that’s running Mongo 6 for my db
  • Update my local dev system to Meteor 2.12 and push to Galaxy

Is that correct? I want to be very careful so as to avoid any unintended downtime. :slight_smile:

2

When you say your dev system you mean also the
embedded mongodb right?

This is only an issue in the embedded one as it includes files from mongo as well and not only your data.

You should be fine in production but you can run locally pointing to your remote db if you want to be sure.

3

Yes, the MongoDB that is installed and launched automatically by Meteor. I’m getting that error 62 with that one.

So in other words, I can update locally to Meteor 2.12, and then connect to my production MongoDB and see if everything is okay? If so that sounds like a great way to proceed.

4

Never do that. You can destroy your production data with a simple mistake in your local environment.

1 Like
5

Thanks for pointing this out! What would be the best procedure in this case, i.e. avoiding downtime in production when updating to Meteor 2.12?

6

Better send a support ticket to Galaxy support

7

Yes, I have. They replied:

Those steps you said might work fine, but as it is a productive environment, I would test it before in a more real scenario.

I suggest you start a staging environment in the Galaxy with the same code and a copy of the database. You create this update-only environment and delete it after updating

You can create a copy of your database in the MongoDB Atlas very quickly and start a new app in the galaxy very quickly too!

That sounds like a good way to proceed.

8

Okay, I got my production MongoDB updated to v6, and my prod app updated to use it.

Here are notes for anyone who, like me, was/will be doing this for the first time.

There are no doubt a lot of ways to do it, and I am only listing the ones I know about so far.

  • Back up your current Meteor folder. I have offsite and onsite backups, but I still like to make a zip file containing my entire Meteor folder, which includes my current Mongo db.
  • Follow the instructions in this thread to backup your local Mongo db, update Meteor to the latest version, and restore your local Mongo db.
  • Install mongosh . I’m on a Mac so I used brew install mongosh
  • Run this to export your current database: mongodump --uri="mongodb+srv://USERNAME:PASSWORD@old-mongodb-hostname" You run it in the terminal, not in mongosh.
  • This will create a folder called “dump” on your local computer. It will contain your database export files.
  • Go to your mongodb host and create a new empty database, called, e.g. “new-mongo-db”.
  • In your terminal, cd to the folder that contains the “dump” folder and run mongorestore --uri="mongodb+srv://USERNAME:PASSWORD@new-mongo-db-hostname/
  • Change your mongo connection strings in your Meteor app to use the connection string for your new db.

That’s kind of the hard way. I found out later that my Mongodb host (MongoDB.com) has a lot of easier ways to do it. :slight_smile: There’s a backup/restore tab they have. It’s on the far right under the name of your db in the db overview page.

Now, what about testing? Galaxy support recommended pushing your app to a staging deployment and testing there. I wanted to avoid that as it’s just one more thing to figure out that I haven’t done before. I thought I might just connect to my new production db from localhost and see if everything was working. At the same time, @rjdavid wisely cautioned that this was dangerous as I could potentially destroy my production db.

However, I kind of thought that at least in my specific instance it might be okay, because if I destroyed my new db I could wipe it and start over, and I had backups even of my old db.

So this may have exposed me to some danger, but I used that approach. Everything went okay. I pushed to production and everything was still working. I then went to MongoDB.com and paused (not terminated) my old db as a way of confirming that my production app was really connecting to my new db. That was confirmed.

I hope this may be useful to others in the future, and won’t mind any corrections/improvements posted here by other forum members.

9

Doing things easier and with more control:

  1. Check this: Updating from 1.6.1.1 to 1.7-rc.2 leads to Mongo exit code 62 · Issue #9871 · meteor/meteor · GitHub
  2. Studio 3T has a free version that allows for full exports/imports (dump/restore) and you can connect to local, live etc and see your DBs running with the versions they are running. More visual les console commands.
1 Like
10

From this link:

From mongo shell before you update you need to run

db.adminCommand( { setFeatureCompatibilityVersion: “3.4” } )

Should we update that to db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } ) if updating from v5? And, does that restrict future use of the db to old features, or does it apply only during the update?

11
1 Like