0

We have a few environments with MongoDB 3.0, these are standalone servers. These servers are already using WiredTiger Storage engine. I am trying to upgrade them to 4.2.

As per the upgrade documentation you can't go from 3.0 to 4.2 but have to make incremental upgrades from 3.0 to 3.2 and so on to 4.2.

As this is something that is going to be repeated on multiple env's I am trying to automate it where in a script does the upgrade but at certain points in the upgrade gives out diagnostic info that someone can look at and confirm that a step in the upgrade process has been successful.

Doing this on EC2 instances with Amazon Linux 2.

To test this out I did a manual upgrade from 3.0 to 3.2. The processes came up fine, I was able to connect to the db and query a collection and everything "seems" fine. Across various DB's the total size of the data is approx 2.3TB, and I was surprised that after the upgrade the DB came up in a few seconds.

I was looking at diagnostic commands to figure out if I can verify in the script that the upgrade happened without a hitch. (Other than the mongod process starting correctly). The only thing I could find was this. https://docs.mongodb.com/v3.2/reference/command/serverStatus/#asserts And am not sure if this is good enough.

So TL;DR; Can I programatically verify that the upgrade was successful by looking at any metadata from the DB itself.

Note: a tangential question, YAML is current preferred config file format, as it is supported even with 4.2 any issues continuing with it?

0

Can I programatically verify that the upgrade was successful by looking at any metadata from the DB itself?

Yes, you can use shell scripts to redirect input/output of a mongo shell.

Beware that scripted mongo shell behaves differently than the interactive mongo shell: https://docs.mongodb.com/manual/tutorial/write-scripts-for-the-mongo-shell/#differences-between-interactive-and-scripted-mongo

a tangential question, YAML is current preferred config file format, as it is supported even with 4.2 any issues continuing with it?

From https://docs.mongodb.com/manual/reference/configuration-options/ :

Changed in version 2.6: MongoDB 2.6 introduced a YAML-based configuration file format. The 2.4 configuration file format remains for backward compatibility.

MongoDB configuration files use the YAML format.

With YAML being the official format, there is no issue. The old format was deprecated, it should still work, but I wouldn't bet that this will never be removed in the future.


About the upgrade procedure (as described here), I imagine you should evaluate the result of rs.status(), but as you are running standalone, I see why you use asserts from db.serverStatus(). In your case, I would be more worried when restarting the mongod process, an exit code was returned.

  • 1
    Process exit code is one part but other than that do we have any indications that the server is ready to accept connections is what I was trying to get at. – Yogesh_D Sep 22 at 8:06
  • @Yogesh_D Well, even when connected, there is no guarantee that commands on the databases and collections will not fail or crash. But for testing connections, only starting the mongo client shell specifying a connection string, would tell enough. – Marcos Zolnowski Sep 22 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.