MongoDB InPlace Version Upgrade 3.4x to 3.6x



Today I am putting simple and straight forward steps to in-place upgrade / downgrade mongoDB single as well as replica set cluster.

Note: Steps are for CentOS kindly modify for other OS.
Warning: IMPORTANT Always backup all of your data before upgrading MongoDB and test steps in nonprod env first.

1. Checking compatibility version
db.system.version.find();
2. setting compatiblity version
db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
3. change dir
cd /tmp/
4. download pkgs (link)

5. cd home
cd
6. stopping mongo
systemctl stop mongod
7. backing up conf
cp /etc/mongod.conf /tmp/
8. removing current Binary
yum remove mongod*
9. cd download dir
cd /tmp/
10. installing newly downloaded mongo server
yum install mongodb-org-server-3.6.14-1.el7.x86_64.rpm
11. installing newly downloaded mongo shell
yum install mongodb-org-shell-3.6.14-1.el7.x86_64.rpm
12. copying back mongo conf
cp mongod.conf /etc/
13. starting mongo
systemctl start mongod
To upgrade a replica set, upgrade each member individually, starting with the secondaries and finishing with the primary. Plan the upgrade during a predefined maintenance window.

Upgrade Secondaries

Upgrade each secondary separately as follows:
  1. Upgrade the secondary’s mongod binary by following the above instructions.
  2. After upgrading a secondary, wait for the secondary to recover to the SECONDARY state before upgrading the next instance. To check the member’s state, issue rs.status() in the mongo shell.
  3. The secondary may briefly go into STARTUP2 or RECOVERING. This is normal. Make sure to wait for the secondary to fully recover to SECONDARY before you continue the upgrade.

Upgrade the Primary

1. Step down the primary to initiate the normal failover procedure. Using one of the following:
  • The rs.stepDown() helper in the mongo shell.
  • The replSetStepDown database command.
During failover, the set cannot accept writes. Typically this takes 10-20 seconds. Plan the upgrade during a predefined maintenance window.
2. Once the primary has stepped down, call the rs.status() method from the mongo shell until you see that another member has assumed the PRIMARY state.
3. Shut down the original primary and upgrade its instance by following the above instructions.

Ref:

Comments

  1. This comment has been removed by the author.

    ReplyDelete
  2. Hi Thanks for the article.

    Could you please answer the below with regards to Windows Environment.

    a)Shut down the mongod instance on Server and replace the 4.0 binary with the 4.2 binary.
    b) Restart the node.

    Replace the binary means, run the new version msi installer which will overwrite old binary or Manually remove 4.0\bin and replace it with 4.2\bin

    Thanks

    ReplyDelete
  3. I entre that publish and were given it great and informative.Please proportion extra considering that. Win 7 Ultimate Product Key

    ReplyDelete
  4. this is such a satisfying aid that you are supplying and you pay for it away for pardon.I liked your engagement intensely thanks Happy Brothers Day Quotes

    ReplyDelete

Post a Comment

Popular posts from this blog

Shell/Bash Commands Execution from MySQL Client or Stored Procedure/function

How to remove/deregister an instance from PMM?

MySQL: How to monitor MySQL Replication Lag in MilliSeconds With PMM and pt-heartbeat