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.
Regards,
Stennie