Skip to main content

Upgrade MongoDB 3.4 to 4.4

Note
  • The time required for the upgrade depends on the number of collections in the MongoDB database.
    You can check the number of collections with the command find /data/mongodb/ -name '*collection*' | wc -l.
    For example, upgrading with less than 10,000 collections may take 1 minute, 100,000 collections may take about 10 minutes, and 300,000 collections may take around 30 minutes; this can also be affected by server disk performance.

  • In the example commands below, the path to the MongoDB program is /usr/local/mongodb/, and the data directory is /data/mongodb/. Modify the commands accordingly if different.

Single Node

Preparation

  1. Follow the details in Docker Installation to install Docker on the MongoDB server.

  2. Pull the upgrade auxiliary mirror (Download Offline Package).

    docker pull nocoly/hap-sc-upgrade:1.0.0
  3. Download the installation package for MongoDB v4.4.29 and upload it to the server

    https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-4.4.29.tgz
  4. Unzip the installation package of MongoDB v4.4.29 and check if the mongod program in the package is missing dependencies. If dependencies are missing, install them accordingly.

    Unzip the installation package of MongoDB v4.4.29.

    tar xvf mongodb-linux-x86_64-rhel70-4.4.29.tgz

    Check if the mongod program in the package is missing dependencies.

    ldd mongodb-linux-x86_64-rhel70-4.4.29/bin/mongod

Start Upgrading

Upgrading MongoDB must be done version by version. If you want to upgrade MongoDB from 3.4 to 4.4, you need to upgrade MongoDB to 3.6, 4.0, 4.2, and finally 4.4, executing the upgrade command 4 times.
During the upgrade, if it prompts that the versions do not match, you need to repeat the previous upgrade command (for example, if upgrading from 3.4 to 3.6 is successful, but upgrading from 3.6 to 4.0 fails, then you need to execute the 3.4 to 3.6 command again until it outputs "exit upgrade"). If the error persists after multiple attempts, you can check the reason in /data/mongodb/upgrade-xxxx.log.

  1. Stop the microservices

  2. Back up the MongoDB data

  3. Stop the existing MongoDB instance

    systemctl stop mongodb
  4. Upgrade MongoDB version

    3.4 to 3.6

    docker run -i --rm -v /data/mongodb:/data/mongodb nocoly/hap-sc-upgrade:1.0.0 <<< 'upgradeMongodb.sh 3.4 3.6'

    3.6 to 4.0

    docker run -i --rm -v /data/mongodb:/data/mongodb nocoly/hap-sc-upgrade:1.0.0 <<< 'upgradeMongodb.sh 3.6 4.0'

    4.0 to 4.2

    docker run -i --rm -v /data/mongodb:/data/mongodb nocoly/hap-sc-upgrade:1.0.0 <<< 'upgradeMongodb.sh 4.0 4.2'

    4.2 to 4.4

    docker run -i --rm -v /data/mongodb:/data/mongodb nocoly/hap-sc-upgrade:1.0.0 <<< 'upgradeMongodb.sh 4.2 4.4'
  5. Replace the existing package with the installation package of v4.4.29

    mv /usr/local/mongodb /usr/local/mongodb.bak-v3.4
    cp -r mongodb-linux-x86_64-rhel70-4.4.29 /usr/local/mongodb
    chown -R mongodb:mongodb /usr/local/mongodb
    • Copy the installation package for MongoDB v4.4.29, the actual name may vary
  6. Modify the MongoDB startup command parameters,and add the --bind_ip 0.0.0.0 parameter

    vim /etc/systemd/system/mongodb.service

    # Append the `--bind_ip 0.0.0.0` parameter after the ExecStart command
  7. Reload systemd and start MongoDB

    systemctl daemon-reload
    systemctl start mongodb
  8. Log in to MongoDB and query featureCompatibilityVersion

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin
    > db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
    • If the output is { "featureCompatibilityVersion" : { "version" : "4.4" }, "ok" : 1 }, the upgrade is successful.

Replica Set

Preparation

  1. Download the necessary MongoDB installation packages for each version and upload them to the servers.

    https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-3.6.23.tgz
    https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-4.0.28.tgz
    https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-4.2.25.tgz
    https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-4.4.29.tgz
  2. Unzip the installation packages for each version and check if the mongod program is missing dependencies. If dependencies are missing, install them accordingly.

    Unzip the installation packages for each version

    tar xvf mongodb-linux-x86_64-3.6.23.tgz
    tar xvf mongodb-linux-x86_64-4.0.28.tgz
    tar xvf mongodb-linux-x86_64-rhel70-4.2.25.tgz
    tar xvf mongodb-linux-x86_64-rhel70-4.4.29.tgz

    Check if the mongod program in each package is missing dependencies

    ldd mongodb-linux-x86_64-3.6.23/bin/mongod
    ldd mongodb-linux-x86_64-4.0.28/bin/mongod
    ldd mmongodb-linux-x86_64-rhel70-4.2.25/bin/mongod
    ldd mongodb-linux-x86_64-rhel70-4.4.29/bin/mongod

Start Upgrading

Note
  • Before upgrading, stop the microservices and backup the MongoDB data.

  • Upgrade the replica set by upgrading each node, starting from the SECONDARY node and ending with the PRIMARY node.

To upgrade from 3.4 to 3.6:

  1. Upgrade the SECONDARY nodes of the replica set one at a time:

    Stop the current MongoDB instance and replace the existing installation package with the package for version 3.6

    systemctl stop mongodb
    mv /usr/local/mongodb /usr/local/mongodb.bak-3.4
    cp -r mongodb-linux-x86_64-3.6.23 /usr/local/mongodb
    chown -R mongodb:mongodb /usr/local/mongodb
    • Copy the installation package for MongoDB v3.6.23, the actual name may vary
  2. Modify the MongoDB startup command parameters,and add the --bind_ip 0.0.0.0 parameter

    vim /etc/systemd/system/mongodb.service

    # Add the `--bind_ip 0.0.0.0` parameter after the ExecStart command
  3. Reload systemd and start MongoDB

    systemctl daemon-reload
    systemctl start mongodb
    • After starting, try logging in to the node. If you encounter login issues, check the program status or consider slow startup due to large data volume or low disk performance.
  4. The upgrading for two SECONDARY nodes is the same

  5. Degrade the PRIMARY node

    Log in to the MongoDB primary node and use the rs.stepDown() command to downgrade the primary node and force the election of a new primary node.

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > rs.stepDown()
  6. Upgrade the old PRIMARY node following the same steps as upgrading the SECONDARY nodes:

    • Stop the current MongoDB instance and replace the existing installation package with the package for MongoDB 3.6.
    • Modify the MongoDB startup command parameters, and add the --bind_ip 0.0.0.0 parameter
    • Reload systemd and start MongoDB
  7. Log in to the PRIMARY node and set the feature compatibility version to 3.6.

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )
    • The normal output should be:{ "ok" : 1 }

    Check the status of each node

    > rs.status()
    • It should ideally be one PRIMARY and two SECONDARY nodes.

    Query featureCompatibilityVersion

    > db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
    • If the output is { "featureCompatibilityVersion" : { "version" : "3.6" }, "ok" : 1 }, the upgrade to version 3.6 is successful.

To upgrade from 3.6 to 4.0:

  1. Upgrade the SECONDARY nodes of the replica set one at a time:

    Stop the current MongoDB instance and replace the existing installation package with the package for version 4.0

    systemctl stop mongodb
    mv /usr/local/mongodb /usr/local/mongodb.bak-3.6
    cp -r mongodb-linux-x86_64-4.0.28 /usr/local/mongodb
    chown -R mongodb:mongodb /usr/local/mongodb
    systemctl start mongodb
    • Copy the installation package for MongoDB v4.0.28, the actual name may vary.
    • After starting, try logging in to the node. If you encounter login issues, check the program status or consider slow startup due to large data volume or low disk performance.
  2. The upgrading for two SECONDARY nodes is the same

  3. Degrade the PRIMARY node

    Log in to the MongoDB primary node and use the rs.stepDown() command to downgrade the primary node and force the election of a new primary node.

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > rs.stepDown()
  4. Upgrade the old PRIMARY node following the same steps as upgrading the SECONDARY nodes

  5. Log in to the PRIMARY node and set the feature compatibility version to 4.0.

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )
    • The normal output should be: { "ok" : 1 }

    Check the status of each node

    > rs.status()
    • It should ideally be one PRIMARY and two SECONDARY nodes.

    Query featureCompatibilityVersion

    > db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
    • If the output is { "featureCompatibilityVersion" : { "version" : "4.0" }, "ok" : 1 }, the upgrade to version 4.0 is successful.

To upgrade from 4.0 to 4.2:

  1. Upgrade the SECONDARY nodes of the replica set one at a time:

    Stop the current MongoDB instance and replace the existing installation package with the package for version 4.3, and start MongoDB

    systemctl stop mongodb
    mv /usr/local/mongodb /usr/local/mongodb.bak-4.0
    cp -r mongodb-linux-x86_64-rhel70-4.2.25 /usr/local/mongodb
    chown -R mongodb:mongodb /usr/local/mongodb
    systemctl start mongodb
    • Copy the installation package for MongoDB v4.2.25, the actual name may vary.
    • After starting, try logging in to the node. If you encounter login issues, check the program status or consider slow startup due to large data volume or low disk performance.
  2. The upgrading for two SECONDARY nodes is the same

  3. Degrade the PRIMARY node

    Log in to the MongoDB primary node and use the rs.stepDown() command to downgrade the primary node and force the election of a new primary node.

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > rs.stepDown()
  4. Upgrade the old PRIMARY node following the same steps as upgrading the SECONDARY nodes

  5. Log in to the PRIMARY node and set the feature compatibility version to 4.2

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )
    • The normal output should be: { "ok" : 1 }

    Check the status of each node

    > rs.status()
    • It should ideally be one PRIMARY and two SECONDARY nodes.

    Query featureCompatibilityVersion

    > db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
    • If the output is { "featureCompatibilityVersion" : { "version" : "4.2" }, "ok" : 1 }, the upgrade to version 4.2 is successful.

To upgrade from 4.2 to 4.4:

  1. Upgrade the SECONDARY nodes of the replica set one at a time:

    Stop the current MongoDB instance and replace the existing installation package with the package for version 4.4, and start MongoDB

    systemctl stop mongodb
    mv /usr/local/mongodb /usr/local/mongodb.bak-4.2
    cp -r mongodb-linux-x86_64-rhel70-4.4.29 /usr/local/mongodb
    chown -R mongodb:mongodb /usr/local/mongodb
    systemctl start mongodb
    • Copy the installation package for MongoDB v4.4.29, the actual name may vary
    • After starting, try logging in to the node. If you encounter login issues, check the program status or consider slow startup due to large data volume or low disk performance.
  2. The upgrading for two SECONDARY nodes is the same

  3. Degrade the PRIMARY node

    Log in to the MongoDB primary node and use the rs.stepDown() command to downgrade the primary node and force the election of a new primary node.

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > rs.stepDown()
  4. Upgrade the old PRIMARY node following the same steps as upgrading the SECONDARY nodes

  5. Log in to the PRIMARY node and set the feature compatibility version to 4.4

    /usr/local/mongodb/bin/mongo -u root -p password --authenticationDatabase admin

    > db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )
    • The normal output should be: { "ok" : 1 }

    Check the status of each node

    > rs.status()
    • It should ideally be one PRIMARY and two SECONDARY nodes.

    Query featureCompatibilityVersion

    > db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
    • If the output is { "featureCompatibilityVersion" : { "version" : "4.4" }, "ok" : 1 }, the upgrade to version 4.4 is successful.