Shulou(Shulou.com)06/01 Report--

Preface to upgrade MongoDB replica set

Part1: write at the front

This article explains how to upgrade the MongoDB replica set, as well as points for attention. The environment of this article is MongoDB3.2 upgrade MongoDB3.4. If you upgrade the lower version 3.4, you need to upgrade to version 3.2 first. If version 3.4 is found to be incompatible with the application, it can be downgraded to 3.2.

Actual combat

Part1: preparing

Before you begin the upgrade, refer to the compatibility changes in the MongoDB 3.4 documentation to ensure that your application and deployment are compatible with MongoDB 3.4. Resolve incompatibility issues in the deployment before starting the upgrade.

Before upgrading MongoDB, test the application in a temporary environment to ensure that the upgrade proceeds smoothly.

Part2: downgrade limit

After upgrading to 3.4, you cannot downgrade to 3.2.7 or earlier. You can only downgrade to version 3.2.8 or later.

Note: avoid reconfiguring replica sets that contain members of different MongoDB versions, as the permission verification rules may be different in the MongoDB version.

Part3: prerequisites for lower version upgrades

To upgrade a replica set to 3.4, all replica set members must run version 3.2. To upgrade a replica set from an earlier version of MongoDB, first upgrade all members of the replica set to the latest version of 3.2 series, and then follow these steps to upgrade from MongoDB 3.2 to 3.4.

Part4: prerequisites for lower version upgrades

To upgrade a replica set to 3.4, all replica set members must run version 3.2. To upgrade a replica set from an earlier version of MongoDB, first upgrade all members of the replica set to the latest version of 3.2 series, and then follow these steps to upgrade from MongoDB 3.2 to 3.4.

Part5: upgrade a Secondary in the replica first

Close the mongod instance and replace the bin directory of the 3.2binary with the bin directory of the 3.4binary.

Restart the member and wait for the member to return to the Secondary state before upgrading the next Secondary member. To check the status of a member, issue rs.status () in mongo shell.

Primary of the Part6:stepdown replica set

Connect mongo shell to the Primary server and use rs.stepDown () to downgrade the primary server and force other nodes to elect a new Primary server.

Part7: upgrading Primary

When rs.status () shows that the original Primary node has become Secondary and the new PRIMARY has been elected, start upgrading the original Primary node:

Close the database and replace the bin directory of the 3.2binaries with the bin directory of the 3.4binaries.

Start the original Primary node.

Part8: enable the new 3.4features that are not backward compatible

At this point, you can run version 3.4 instead of using 3.4 features that are not compatible with 3.2.

To enable these 3.4 features, set the feature compatible version to 3.4.

Enabling these non-backward compatible features complicates the downgrade process. For more information, see remove 3.4 incompatible features.

It is recommended that after the upgrade, the application does not use 3.4 these features for a period of time to ensure stability. When you confirm that the application is running steadily and require backward-compatible features such as version 3.4, use the following command to enable these features:

The primary node is running:

Db.adminCommand ({setFeatureCompatibilityVersion: "3.4"})

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.