How to migrate MongoDB Shared Cluster to another Hardware

Ops and Admin Sharding
,
#1

Our Current Instances:

MongoDB 3.6

  1. 5 Databases with approximate 980Gb.
  2. 2 x sharded clusters, each cluster has 2 nodes, plus some other administer node such as Mongos, arbiter & config

MongoDB 4.0

  1. Max 6 databases with approximate 565GB
  2. 3 x sharded clusters, each cluster has 2 nodes, plus some other administer node such as Mongos, arbiter & config

We ould like to Migrate Mongo database from current platform (MongoDB 3.6) to new platform MongoDB 5.0 (EOL Oct 2024) or 6.0 (EOL July 2025) .

What is the exact steps to migrate our database from existing hardware into new hardware with the latest version?

Thanks,
Arun.

#2

Welcome to the MongoDB Community @BHARATHARUN_RAMASAMY !

I strongly recommend not doing multiple major changes concurrently (for example: upgrading major release versions and migrating to new hardware). If you encounter any unexpected issues or performance problems, it will be more challenging to figure out which change might have introduced the issue.

if you want to upgrade your sharded clusters while maintaining availability, you will have to plan upgrades between successive major releases: 3.6 => 4.0, 4.0 => 4.2, 4.2 => 4.4, 4.4 => 5.0, 5.0 => 6.0. The most straightforward upgrade path would be using automation tooling such as MongoDB Ops Manager or MongoDB Cloud Manager.

The relevant documentation to review is:

Regards,
Stennie

3 Likes
#3

Hi Stennie,

Thanks a lot for sharing your suggestions. We will take this into our considerations and we will slowly upgrade into the latest versions in new UAT environment first and perform the full functional testing between each upgrade.

Secondly, We are planning to move the whole sharded cluster to completely newer hardware in different location. In this case, How we can migrate the whole setup from one environment to another? How long will it take roughly for 5 databases each 1 TB in size?

And, Is there any option to migrate without any downtime or with minimal down time?

Thanks,
Arun.

#4

It’s completely impossible to tell because it depends on the hardware and the distance (latency) between the 2 locations.

If you want to migrate with zero downtime, it’s possible but you’ll have extra steps. I would take a full backup and restore it in the new location on a new node, then add this node in the replica set (repeat for each RS). Continue to add more nodes in your config until you can start removing nodes in the old location. Check that all the nodes are up-to-date.

You can play with priority settings to make sure the primary stays on the desired side until you are ready to “move”.

Cheers,
Maxime.

#5

Hi Maxime,

Is it possible to migrate directly from 3.6 to the latest 6.0 with downtime?

Thanks,
Arun.

#6

The latest version can only support from 6.0 to 4.2.
Maybe you can use the mongoexport v3.6 and then import with mongoexport 100.5.4 (versioning changed, tools are now independent from the server releases). But there is no guarantee that this is going to work. I would give it a try on a couple of small collections though.

Cheers,
Maxime.

#7

Thanks for sharing this info! It’s really helpful to me
If we upgrade into 4.2 then, can we migrate to 6.0 on new hardware from 4.2 to 6.0? If yes, how we can achieve this? Could you please recommend the best approach?

#8

Hi @BHARATHARUN_RAMASAMY,

Sorry for the delayed answer, I was on extended paternity leave and kinda busy as you can imagine!
I think @Stennie already covered your question about upgrading in this answer here in this topic but please feel free to update us with your new status now and let me know if your migration was successful or not.

Cheers,
Maxime.