Helm upgrade of MongoDB having a Primary-Secondary-Arbiter architecture, is there downtime?

12/10/2020

I am thinking of setting up a bitnami mongodb replicaset in K8s, as explained here.

However, as a note they mention this while upgrading:

Note: An update takes your MongoDB replicaset offline if the Arbiter is enabled and the number of MongoDB replicas is two. Helm applies updates to the statefulsets for the MongoDB instance and the Arbiter at the same time so you loose two out of three quorum votes.

I am not sure what does it actually mean "taking the replicaset offline":

  1. Is it that the whole mongo service goes offline/down and therefore there is downtime on the service when performing helm upgrades?

  2. Is it that, while performing the upgrade, the replicaset will have only one mongodb server working, while both, the other mongo db server and arbiter, are offline and being upgraded?. In this case, it will not imply downtime, just that momentarily, there is just one server available (instead of two), so similar to a standalone setup.

-- FCR
bitnami
kubernetes
kubernetes-helm
mongodb

2 Answers

12/11/2020

Bitnami developer here

Is it that, while performing the upgrade, the replicaset will have only one mongodb server working, while both, the other mongo db server and arbiter, are offline and being upgraded?

That will depend on how many replicas you have. If you install the chart with 2 replicas + 1 arbiter, yes it means that. However, if you install the chart with 4 replicas + 1 arbiter, you'll have only 1 replica and the arbiter being restarted simultaneously, having the other 3 replicas up.

In this case, it will not imply downtime, just that momentarily, there is just one server available (instead of two), so similar to a standalone setup.

As it's mentioned in the previous response, it does imply a small downtime indeed if the minimum quorum of alive replicas it's not meet.

-- Juan Ariza
Source: StackOverflow

12/10/2020

I don't know what Helm is or what it does or why it takes down two nodes at a time, but:

I this case, it will not imply downtime, just that momentarily, there is just one server available (instead of two), so similar to a standalone setup.

A standalone accepts writes whenever it's up. A replica set node accepts writes only if it is the primary node, and to have a primary node a majority of nodes must be up. Therefore if only one out of three nodes of a replica set is up, there cannot be a primary, and no node will accept writes.

With one out of three nodes available, if this node is data-bearing, you can still issue reads using secondary-allowing read preferences (primary preferred or secondary or secondary preferred), but primary reads won't work and writes won't work.

-- D. SM
Source: StackOverflow