MongoDb Replica Set write concern issues on Secondary IP, while Primary IP is Shutdown

[rohit_arora3 (Rohit Arora)]

I am using 4 nodes for my MongoDB replica set, one as the primary node, two as a secondary node, and one as an arbitrator node. I am using the following connection string in Golang to connect with MongoDB.

opts = options.Client().ApplyURI("mongodb://" + ipPort + "," + secIpPort +  "," + sec2IpPort + "/?replicaSet=" + repSetName).SetConnectTimeout(5 * time.Second).SetAuth(serverAuth).SetWriteConcern(writeconcern.New(writeconcern.WMajority()))

Ip used to make connection are, ipPort= 192.168.1.237 secipPort= 192.168.1.239, sec2IpPort= 192.168.1.2

In My replica Set( PRIMARY-SECONDAY-SECONDAY-ARBITER (PSSA) ), look like the following:
“majorityVoteCount” : 3,
“writeMajorityCount” : 3,
“votingMembersCount” : 4,
“writableVotingMembersCount” : 3

I have setted the Default RW Concern as following,

db.adminCommand({ "setDefaultRWConcern" : 1, "defaultWriteConcern" : { "w" : "majority", "j":true, "wtimeout" : 5000 }, writeConcern: { "w" : "majority", "j":true, "wtimeout" : 5000 }, })

Problem:

When the MongoDb service of the first IP(192.168.1.237) of the connection string is shut down, the secondary IP(192.168.1.239) becomes primary and performs all the read operations well. But does not perform the write operations.

How can I deal with this problem? If the first IP of the connection string is down, the secondary IP/node should be able to perform both read and write operations.

[Aasawari (Aasawari Sahasrabuddhe)]

Hi @rohit_arora3 and welcome to the MongoDB community forum!!

Generally, for a replica set configuration, having odd number of voting members is the recommended method.
Therefore, the addition of an arbiter must be done with the utmost care and planning.

An arbiter in MongoDB only contributes to the voting but does not play any role for the write operations.
As mentioned in MongoDB documentation, if the voting majority is more than the writeConcern majority, the write concern is not acknowledged.

Please visit the documentation on How to Mitigate Performance Issues with PSA Architecture for more details.

Therefore, the recommendation here is to remove the arbiter since it does not add value to the replica set deployment.

Let us know if you have any further questions.

Best Regards
Aasawari