I am testing the possibility of migrating MongoDB by using replicaSets. What I am doing is trying to add a 5.0 MongoDB node to a 3-node replicaSet, which is running version 4.4.6 (both are community MongoDB)
So whe, I run the “rs.add()” on my 4.4.6 primary, I get the below message when describing the members (rs.status().members):
“lastHeartbeatMessage” : “remote host has incompatible wire version: Server min and max wire version (13,13) is incompatible with client min wire version (9,9).You (client) are attempting to connect to a node (server) that no longer accepts connections with your (client’s) binary version. Please upgrade the client’s binary version.”
With the above message, I am assuming that this migration path is not possible and I will have to copy data from the 4.4.6 replicaSet to the new one, in version 5.0. Is that correct or there is a way to overcome this?
The standard approach for upgrading a replica set without downtime is using rolling version upgrades from the previous major release series to the next (eg 4.4 => 5.0). For prerequisites and steps, please see Upgrade a Replica Set to 5.0 in the MongoDB documentation.
In particular, if your 4.4 replica set was previously upgraded from 4.2 please make sure the Feature Compatibility Version is set to 4.4 before trying to add any 5.0 members to the replica set.
So just to be clear, it is not possible to add a member of a different version to a replica set? My original idea was to add 3 new members on the new version to the replica set, and then remove the members with the old version.
I have the same situation as Fabricio, and I want to know if the solution of adding 3 new nodes with 5.0 version of MongoDB to a 4.4 version of replica set is available or not.
Welcome to the MongoDB Community Forums @Mikel_Pikabea (and apologies for missing your follow-up question @Fabricio_Jorge)!
As @chris suggested, I would ideally add new members to your replica set either before or after the 4.4 upgrade rather than during. Combining hardware migration with a major version upgrade will make it more difficult to isolate the source of any potential performance or upgrade issues and you may encounter unexpected errors venturing outside the normal upgrade path.
If your concern is about potentially needing to downgrade or remain on 4.4 due to critical issues missed during your practice upgrades, note that the major version upgrade process includes an explicit Feature Compatibility Version (FCV) step so you have control over enabling features that may persist backward-incompatible data and complicate a potential downgrade.
The supported replica set upgrade scenario that has been thoroughly tested is a rolling upgrade of each of your 4.4 members to 5.0. The members can be a mix of 4.4 and 5.0 binary versions transiently during the upgrade process, but all members need to have Feature Compatibility Version (FCV) set to 4.4. A newly created 5.0 replica set member will start with FCV of 5.0 and result in error messages similar to @Fabricio_Jorge’s first post.
If you want to add new 5.0 members before the upgrade is complete, an approach that should work with the standard upgrade process would be:
Upgrade one of your secondaries from 4.4 to 5.0 (FCV needs to remain 4.4). Consider making this hidden and priority 0 prior to upgrade to avoid disrupting any production traffic if you are using secondary reads.
Shutdown this secondary and take a file copy backup to seed the new 5.0 members you want to add (make sure you have sufficient oplog coverage).
Add the newly seeded 5.0 members to your replica set configuration (perhaps initially as hidden and priority 0 if you need to further validate).
When you have validated the new members, remove or hide the older 4.4 members from your replica set configuration.
Throughout the process you will need a quorum of configured voting members available in order to elect (or sustain) a primary. I would thoroughly test with representative data, workloads, and deployment resources in a staging or QA environment so you are comfortable with the upgrade procedures and outcomes.