Upgrade from 4.0 to 4.2 without downtime in PSA replicaset

I am upgrading Mongo replicaset from 3.4 → 4.2. Last week I did the upgrade fro 3.6 → 4.0 and the next step is to upgrade from 4.0 → 4.2.
During the upgrade fro 3.6 to 4.0, we faced some issues due to read concern majority.
After we stepped down the primary, there was some issue in the old primary and took a lot of time for this instance to be back up and running. now since we have read concern majority and w:1 , writes were successful, but the reads were failing because the majority was not satisfied.
And after sometime there was performance issue on the new primary and some writes also started timing out and the overall response time increased.

In the next upgrade i.e fro 4.0 to 4.2, we might face this issue again. is there a way to do this upgrade without read and write failures?

Hi @Ishrat_Jahan,

After we stepped down the primary, there was some issue in the old primary and took a lot of time for this instance to be back up and running.

The main issue here is that a PSA setup will always have issues with read and write majority when one of the data-bearing node goes offline. Some possibly being:

And after sometime there was performance issue on the new primary and some writes also started timing out and the overall response time increased

Can you confirm when this issue happens whether or not the SECONDARY was up when the new PRIMARY was up? I.e. PSA.
Or was it a case where the SECONDARY was offline and the new PRIMARY was up? I.e. PXA (Where X is an offline node, specifically the SECONDARY in this scenario).

In the next upgrade i.e fro 4.0 to 4.2, we might face this issue again. is there a way to do this upgrade without read and write failures?

Unfortunately due to the nature of a PSA set, you will encounter this issue if any data-bearing node is offline for an extended period of time. However, there are workaround for this, as shown in the following procedure is followed.

Lastly, regarding the PSA set up as well, you may find information on Stennie’s response specifically regarding “Should you add an Arbiter?” on this topic useful.

Regards,
Jason

3 Likes

Thanks for your input. We have decided to add a secondary and remove the arbiter. Effectively converting the setup from PSA to PSS. SO we should not face such issues during the maintenance process.

3 Likes

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.