Upgrading to Percona Server for MongoDB 3.4 from Previous Versions

Upgrading to Percona Server for MongoDBThis post is another in the series on the Percona Server for MongoDB 3.4 bundle release. In this blog post, we will walk through upgrading to Percona Server for MongoDB 3.4 from a previous MongoDB version. We will highlight the important details to guarantee the successful completion of this task in your environment.

MongoDB 3.4 was just released, and it has a lot of new features such as views, a better sharding algorithm, facet aggregation, numeric precision data type and more.

The procedure below covers upgrading from a previous version. The process for a fresh installation is slightly different. We don’t need to enable compatibility (as explained later).

Before upgrading, please be aware of a few details/requirements:

  • Minimum versionThe minimum version required to upgrade to MongoDB 3.4 is 3.2.8.
  • Config serversConfig servers only work as replica sets. The previous method – instances as config servers – is no longer supported.
  • DriverThe driver must be ready for the new features (such as views and decimal data type). Please make sure that your driver version contains all the required settings.

How to upgrade a MongoDB config server instance (the previous config server architecture) to a replica set

  1. Check if the balancer is running. If it is, disable the balancer process:

  1. Connect to the first MongoDB config server and run the command below. Please replace the _id and members with your own settings:

Get the storage engine name that is used by this instance. We will use this information later. If you are using MMAPv1, there are some additional commands to run:

Use the following command to read all the application startup parameters (informational only):

  1. Restart the first MongoDB config instance with the replSet configRS and  configsvrMode=sccc parameters:

If using a configuration file, you must use the following parameters:

  1. After the first config server has been restarted, start two empty config servers with the parameters settings chosen before. If you are using MMAPv1, please start three instances instead of two.

  1. Connect to the first config server again and add the new instances to the replica set:

  1. Check the replication status. All the new instances must be in secondary status (part of the output has been omitted in the rs.status (below):

  1. Once the replica set is up and running, please stop old config instances running without replica set. Also, add the votes and priority to all members of the replica set. If using MMAPv1, remove votes and priority from cfg.members[0];:

  1. Restart the mongos service using the new replica set repl/hostnames:port and the configdb parameter:

  1. Perform a stepDown() and shutDown() in the first server. If this server is using MMAPv1, remove it from the replica set using rs.remove(). If it is using wiredTiger, restart without configsvrMode=sccc in the parameters.

At this point, you have an instance that has been correctly migrated to a replica set.

  1. Please enable the balancer again (use a 3.4 client, or it will fail):

How to upgrade config instances server to version 3.4

Please follow these instructions to upgrade a shard to the 3.4 version.

As we already have the configs correctly running as replica sets, we need to upgrade the binaries versions. It is easy to do. Stop and replace the secondaries binaries versions:

  1. Connect to the mongos and stop the balancer.
  2. Stop the secondary, replace the old binary with the new version, and start the service.
  3. When the primary is the only one running with version 3.2, run rs.stepDown()  and force this instance to become secondary.
  4. Replace these (now) secondary binaries with the 3.4 version.

For the shards, add a new parameter before restarting the process in the 3.4 version:

  1. Stop the secondaries, replace the binaries and start it with the shardsvr parameter.

If using a config file, add (this is a new parameter in this version):

  1. Step down the primary and perform this same process on it.
  2. After all the shards binaries have been changed to the 3.4 version, upgrade the mongos binaries.
  3. Stop mongos and replace this executable with the 3.4 version.

At this point, all the shards are running the 3.4 version, but by default the new features in MonogDB 3.4 are disabled. If we try to use a decimal data type, mongos reports the following:

In order to enable MongoDB 3.4 features we need run the following in the mongos:

After changing the featureCompatibility to “3.4,”  all the new MongoDB 3.4 features will be available.

I hope this tutorial was useful in explaining upgrading to Percona Server for MongoDB 3.4. Please ping on twitter @adamotonete or @percona for any questions and suggestions.

Share this post

Comment (1)

  • Abutalib Zaidi

    Hi Adamo,

    While using this great blog of yours to convert mirrored config servers to a replica set with authentication enabled, I found out that in step 7, you should not stop the old mirrored config servers because it breaks the mongos connection to the config servers. Instead, after doing step 8 (restarting mongos with replicaset configsvr list) then you should/can stop old config servers. I hope this helps. Thx!

    September 27, 2018 at 9:06 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.