Upgrade Procedure for MongoDB

Ops and Admin Installation & Upgrades
,
1

Hi,

I need to upgrade my mongodb replicaSet from 4.2 to 5.0.
I realize I need to upgrade to 4.4 first, and then to 5.0
My question is in regards to the upgrade procedure.

My Mongo is running on docker containers, which were created and deployed using Ansible playbook.
Now that I need to upgrade I do the following:

  1. deploy the existing containers using mongo 4.4 image.
    – when this is finished, I can see that all containers are deployed successfully, and are using version 4.4

  2. Connect to each secondary mongo container, and run:

mongod --upgrade

The output looks like this:
mongod --upgrade

{“t”:{“$date”:“2023-05-16T14:10:40.788+03:00”},“s”:“I”, “c”:“NETWORK”, “id”:4915701, “ctx”:“-”,“msg”:“Initialized wire specification”,“attr”:{“spec”:{“incomingExternalClient”:{“minWersion”:13},“incomingInternalClient”:{“minWireVersion”:0,“maxWireVersion”:13},“outgoing”:{“minWireVersion”:0,“maxWireVersion”:13},“isInternalClient”:true}}}
{“t”:{“$date”:“2023-05-16T14:10:40.789+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:23285, “ctx”:“-”,“msg”:“Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledP
{“t”:{”$date":“2023-05-16T14:10:40.791+03:00”},“s”:“W”, “c”:“ASIO”, “id”:22601, “ctx”:“main”,“msg”:“No TransportLayer configured during NetworkInterface startup”}
{“t”:{“$date”:“2023-05-16T14:10:40.791+03:00”},“s”:“I”, “c”:“NETWORK”, “id”:4648601, “ctx”:“main”,“msg”:“Implicit TCP FastOpen unavailable. If TCP FastOpen is required, set tcpFastOlient, and tcpFastOpenQueueSize.”}
{“t”:{“$date”:“2023-05-16T14:10:40.825+03:00”},“s”:“W”, “c”:“ASIO”, “id”:22601, “ctx”:“main”,“msg”:“No TransportLayer configured during NetworkInterface startup”}
{“t”:{“$date”:“2023-05-16T14:10:40.825+03:00”},“s”:“I”, “c”:“REPL”, “id”:5123008, “ctx”:“main”,“msg”:“Successfully registered PrimaryOnlyService”,“attr”:{“service”:“TenantMigrationfig.tenantMigrationDonors”}}
{“t”:{“$date”:“2023-05-16T14:10:40.825+03:00”},“s”:“I”, “c”:“REPL”, “id”:5123008, “ctx”:“main”,“msg”:“Successfully registered PrimaryOnlyService”,“attr”:{“service”:“TenantMigrati”:“config.tenantMigrationRecipients”}}
{“t”:{“$date”:“2023-05-16T14:10:40.825+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:5945603, “ctx”:“main”,“msg”:“Multi threading initialized”}
{“t”:{“$date”:“2023-05-16T14:10:40.825+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:4615611, “ctx”:“initandlisten”,“msg”:“MongoDB starting”,“attr”:{“pid”:136,“port”:27017,“dbPath”:“/data/dbt”,“host”:“10.97.7.150”}}
{“t”:{“$date”:“2023-05-16T14:10:40.826+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:23403, “ctx”:“initandlisten”,“msg”:“Build Info”,“attr”:{“buildInfo”:{“version”:“5.0.15”,“gitVersion”:“9854b831107c0b118”,“openSSLVersion”:“OpenSSL 1.1.1f 31 Mar 2020”,“modules”:,“allocator”:“tcmalloc”,“environment”:{“distmod”:“ubuntu2004”,“distarch”:“x86_64”,“target_arch”:“x86_64”}}
{“t”:{“$date”:“2023-05-16T14:10:40.826+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:51765, “ctx”:“initandlisten”,“msg”:“Operating System”,“attr”:{“os”:{“name”:“Ubuntu”,“version”:“20.04”}}
{“t”:{“$date”:“2023-05-16T14:10:40.826+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:21951, “ctx”:“initandlisten”,“msg”:“Options set by command line”,“attr”:{“options”:{“upgrade”:true}}}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“E”, “c”:“CONTROL”, “id”:20557, “ctx”:“initandlisten”,“msg”:“DBException in initAndListen, terminating”,“attr”:{“error”:“DBPathIe lock file: /data/db/mongod.lock (Resource temporarily unavailable). Another mongod instance is already running on the /data/db directory”}}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“REPL”, “id”:4784900, “ctx”:“initandlisten”,“msg”:“Stepping down the ReplicationCoordinator for shutdown”,“attr”:{“wai
{“t”:{”$date":“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“COMMAND”, “id”:4784901, “ctx”:“initandlisten”,“msg”:“Shutting down the MirrorMaestro”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“SHARDING”, “id”:4784902, “ctx”:“initandlisten”,“msg”:“Shutting down the WaitForMajorityService”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“NETWORK”, “id”:20562, “ctx”:“initandlisten”,“msg”:“Shutdown: going to close listening sockets”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“NETWORK”, “id”:4784905, “ctx”:“initandlisten”,“msg”:“Shutting down the global connection pool”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:4784906, “ctx”:“initandlisten”,“msg”:“Shutting down the FlowControlTicketholder”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“-”, “id”:20520, “ctx”:“initandlisten”,“msg”:“Stopping further Flow Control ticket acquisitions.”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“NETWORK”, “id”:4784918, “ctx”:“initandlisten”,“msg”:“Shutting down the ReplicaSetMonitor”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“SHARDING”, “id”:4784921, “ctx”:“initandlisten”,“msg”:“Shutting down the MigrationUtilExecutor”}
{“t”:{“$date”:“2023-05-16T14:10:40.930+03:00”},“s”:“I”, “c”:“ASIO”, “id”:22582, “ctx”:“MigrationUtil-TaskExecutor”,“msg”:“Killing all outstanding egress activity.”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“COMMAND”, “id”:4784923, “ctx”:“initandlisten”,“msg”:“Shutting down the ServiceEntryPoint”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:4784925, “ctx”:“initandlisten”,“msg”:“Shutting down free monitoring”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:4784927, “ctx”:“initandlisten”,“msg”:“Shutting down the HealthLog”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:4784928, “ctx”:“initandlisten”,“msg”:“Shutting down the TTL monitor”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:4784929, “ctx”:“initandlisten”,“msg”:“Acquiring the global lock for shutdown”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“-”, “id”:4784931, “ctx”:“initandlisten”,“msg”:“Dropping the scope cache for shutdown”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“FTDC”, “id”:4784926, “ctx”:“initandlisten”,“msg”:“Shutting down full-time data capture”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:20565, “ctx”:“initandlisten”,“msg”:“Now exiting”}
{“t”:{“$date”:“2023-05-16T14:10:40.931+03:00”},“s”:“I”, “c”:“CONTROL”, “id”:23138, “ctx”:“initandlisten”,“msg”:“Shutting down”,“attr”:{“exitCode”:100}}

  1. Stop the Primary container. so now one of the other nodes becomes the Primary.

  2. Start this container (which is now secondary) and run the mongod --upgrade command as well.

  3. Connect to the Primary container mongo shell and run the following command:
    db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } );

when I finish all this, I seem to have a healthy replicaset, with version 4.4

My question is this:
In most documented upgrade instructions I do not see the requirement to use the mongod --upgrade
In what cases is this required, and when can it be skipped?

Thanks,
Tamar

3

Hi @Tamar_Nirenberg and welcome to MongoDB community forums!!

While upgrading or downgrading the MongoDB version, the binaries of the specific version needs to be replaced with the desired version.
This replacing of the binaries is similar to changing the image with the relevant tags in the docker-compose files.
Therefore, in a containerised environment, changing the image tag would perform the upgrade to the respective version.

However, there are few points to consider before the upgrade.

  1. For the production environment, the upgrade of the replica set should be done should be done in the rolling fashion, i.e, first upgrade the secondaries and then finally upgrade the primary member of the replica set.

  2. Remember to map the volumes to the correct path during the upgrade process else this may lead to data log.

  3. Finally, for the upgrade process, it should be in accordance with your specific environment i.e. if you’re using Ansible and Docker, then the basic procedure need to be tailored for that environment

However to answer your question, the mongod --upgrade is not the necessary procedure while performing the upgrade in the docker environment.

Let us know if you have any further questions.

Regards
Aasawari

4

Hi @Aasawari,

Thank you for the clarification!
Is there a relation between the size of the data and the time it takes to upgrade?

Thanks,
Tamar

5

NO.

upgrading means changing the binaries (code) and config files, which has nothing to do with data size. (size only, others may matter, e.g. data format on disk).