1

I use mongodb 4.0.10. I want to establish a quorum for a cluster of one primary node and two secondary nodes as written here. When the number of nodes is less than the quorum, 3 nodes in my case, cluster goes to readonly (no election).

I`ve tried to set priority of two nodes to 0, in this case if primary goes down, there is no election, but if one of secondaries goes down, old primary still exists.

According to MongoDB docs terminology is it possible to set a replica set Fault Tolerance to zero? It means that if any of cluster nodes goes down new primary will not be elected.

UPDATE
rs.conf():

rs0:PRIMARY> rs.conf()
{
        "_id" : "rs0",
        "version" : 4,
        "protocolVersion" : NumberLong(1),
        "writeConcernMajorityJournalDefault" : true,
        "members" : [
                {
                        "_id" : 0,
                        "host" : "mongo0:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {

                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 1
                },
                {
                        "_id" : 1,
                        "host" : "mongo1:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 0,
                        "tags" : {

                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 0
                },
                {
                        "_id" : 2,
                        "host" : "mongo2:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 0,
                        "tags" : {

                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 0
                }
        ],
        "settings" : {
                "chainingAllowed" : true,
                "heartbeatIntervalMillis" : 2000,
                "heartbeatTimeoutSecs" : 10,
                "electionTimeoutMillis" : 10000,
                "catchUpTimeoutMillis" : -1,
                "catchUpTakeoverDelayMillis" : 30000,
                "getLastErrorModes" : {

                },
                "getLastErrorDefaults" : {
                        "w" : 1,
                        "wtimeout" : 0
                },
                "replicaSetId" : ObjectId("5cf5011183ea2fa5beade86b")
        }
}

I want to set a quorum rule to 3. It`s a split-brain protection measure. It means that if no 3 alive nodes in the cluster there is no able to write, only to read. I set priority of secondary nodes to 0, it means that if primary fails - no new primary will be elected. It works fine, but I also want to configure such primary node behaviour: if any secondary nodes are not available in the cluster - primary change status to secondary till all cluster members will be available again.

2
  • A fault tolerance of 0 would mean that in the event any node is unavailable you would have no primary. If you have 3 data bearing members in a default configuration the fault tolerance is 1 (so any single node can be unavailable). If you set two of your members to priority 0, they cannot be elected as primary so you have a write fault tolerance of 1 (if either secondary is unavailable) or 0 (if the only member eligible to be primary is unavailable). Can you edit your question to include current rs.conf() details and clarify what outcome you are hoping for? For example, do you want failover?
    – Stennie
    Jun 9, 2019 at 0:08
  • Cluster should be in read-only if any of the nodes are not available and if all nodes are in the cluster - then we can perform write operations, thats all. Jun 9, 2019 at 9:57

2 Answers 2

0

I want to set a quorum rule to 3. It`s a split-brain protection measure. It means that if no 3 alive nodes in the cluster there is no able to write, only to read.

Split brain usually refers to a scenario where you have inconsistent data on both sides of a partition, for example with different writes accepted. The quorum requirement in MongoDB replication is designed to avoid that: a primary can only be elected (or sustained) in a partition that has a majority of configured voting members available. Any minority partitions will be increasingly stale, but will still have consistent history with a possibility of resuming sync when the network partition is resolved.

I also want to configure such primary node behaviour: if any secondary nodes are not available in the cluster - primary change status to secondary till all cluster members will be available again.

This is an atypical configuration since it does not allow for any fault tolerance for writes (which is one of the key benefits of replica sets). A recommended approach would be configure all of your nodes as voting, use w:majority to require majority writes, and use read concern majority to ensure documents read are guaranteed not to roll back. The maxStalenessSeconds read preference can also be useful if you are concerned about reading from a secondary that has fallen too far behind.

However, if you want to ensure writes only succeed with all members available, you could consider one of the following approaches:

  • Use a w:3 write concern to require acknowledgement from all 3 members of your replica set.
  • Configure your replica set with 2 replica set members (instead of 3) which are both voting. This will require both members online in order to elect or sustain a primary.
1
  • Thanks! I set w=3 in my pymongo.MongoClient args. Jun 10, 2019 at 13:01
0

setting w:3 will require acknowledgement from all 3 members of your replica set however if anyone of them is not available, write will be done in the cache file of the primary and which may lead a disk full scenario if down time is large. I believe w:majority is the best approach with a Primary secondary secondary configuration.

Meanwhile it will be great if you could please share why you want your cluster to be read only even if only one member is down? It is simply loosing the high availability of your cluster. if you want just to make sure read is not dirty read I think w:majority will allow to read data which will not be roll backed.

Your Answer

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

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