We have MongoDB 3.6.9 replica set, contains 3 data nodes and 2 arbiters.

I noticed warning in mongodb console:

2020-01-20T11:29:04.057+0000 I REPL     [replexec-0] ** WARNING: This replica set uses arbiters, but readConcern:majority is enabled 
2020-01-20T11:29:04.057+0000 I REPL     [replexec-0] **          for this node. This is not a recommended configuration. Please see 
2020-01-20T11:29:04.057+0000 I REPL     [replexec-0] **          https://dochub.mongodb.org/core/psa-disable-rc-majority-3.6

I studied the material from the link https://dochub.mongodb.org/core/psa-disable-rc-majority-3.6, but I did not understand why it needs to disable majority RC, and what will be better: remove arbiters or disable majority RC.

2 Answers 2


Arbiter nodes don't "replicate" data...

The problem with your setup is that, that you can "lose" two of your three data-bearing nodes and your setup has still "majority" in votes. Meaning that replica set still keeps "serving" clients, but all data is only at the one node without replication.

Then comes that "majority RC", with that setup, even you lose one of those data-bearing nodes, the whole replica set stops accepting data (basically) because of missing ack messages. If three nodes of five are data-bearing nodes, that three IS majority of nodes and "majority RC" required that all those three nodes answer "ack, data is safely saved to the storage".


In general arbiters are only useful with an even number of host in a ReplicaSet, so you can remove them.

Regarding your question see Add an Arbiter to Replica Set


In general, avoid deploying more than one arbiter per replica set.

For 3-Member Primary-Secondary-Arbiter Architecture

If you have a three-member replica set with a primary-secondary-arbiter (PSA) architecture or a sharded cluster with a three-member PSA shards, the cache pressure will increase if any data bearing node is down and support for "majority" read concern is enabled.

To prevent the storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture, you can disable read concern “majority” starting in MongoDB 4.0.3 (and 3.6.1+). For more information, see Disable Read Concern Majority.

Bear in mind, you don't have PSA configuration which means:

  • One Primary
  • One Secondary
  • One Arbiter

Deploying more than 1 arbiter might be useful when your nodes are located in several data centers and these hosts are not evenly distributed (e.g. 2 nodes are located in DC1 and 1 node is in DC2).

  • 1
    The caveat on Read Concern Majority applies to a PSSAA deployment (or any where you can lose a majority of data-bearing voting nodes but still maintain a primary). With a PSSAA deployment degraded to PSxAA, the replica set can no longer acknowledge majority writes and there will be increased cache pressure which will degrade performance and eventually immobilise the deployment unless Read Concern Majority is disabled. PSA is the most straightforward case to warn about. Multiple arbiters are definitely not recommended and they will generally increase failure modes rather than adding resilience.
    – Stennie
    Jan 22, 2020 at 8:59
  • Sorry but I'm a little confused about the cache pressure here? What is the replica set caching in this scenario?
    – ncubrian
    Jan 4, 2021 at 3:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.