0

We have deployed mongodb replica set:

mongod --port 27017   --dbpath /opt/eltropy/mongodb/data/rs0-1 --replSet rs0 --smallfiles --oplogSize 128

mongod --port 27018   --dbpath /opt/eltropy/mongodb/data/rs0-1 --replSet rs0 --smallfiles --oplogSize 128

mongod --port 27019   --dbpath /opt/eltropy/mongodb/data/rs0-1 --replSet rs0 --smallfiles --oplogSize 128

What I understand from mongdb documentation; even if your two nodes goes down, we still should be able to read from remaining working nodes (Single working node in this case). However, write is not possible.

But even reads are not working on the available node. I also try to add one arbiter but still no luck. Remaining node still stay in secondary stage.

I am using mongodb 3.0.

1

The reason

The answer is quite simple: when two voting nodes of three are down, the remaining one reverts to secondary, to which – by definition – one can't write. The default read preference is to read from and write to the primary of a replica set only. Hence, when only a secondary remains in the replica set, you can not read.

tl;dr

You have to change your read preference at least to primaryPreferred, allowing reads from secondaries.

-1

MongoDB nodes will vote of who can be next Primary, with a majority of votes.

  • 3 nodes : at least 2 have to choose a certain node. When 2 of the 3 can't vote, the the remaining one, has 1 vote out of 3 => no majority
  • 3 nodes + arbiter : now you have 2 votes out of 4, what is still no majority.

Solutions:

  • You could have a script or manually startup an arbiter for each node that is down.
  • You can reconfigure the replica set with rs.reconfig() to remove the nodes that are down.
  • (You could alter the number of votes in the rs.conf, but mongo strongly advises only to change the number of votes for a node in rare cases.)

(MongoDB has some free university/classes where they explain with exercises how all those situations can be handled.)

  • You don't need a primary to be able to read from a replica set which does not have a primary. As for your solutions: Changing the number of voting members during a failover situation is delicate, at best, removing arbitrary nodes may will cause tied votes in a failover situation and you mentioned yourself that changing the number of votes is strongly discouraged (for good reasons, I might add). Since your solutions are outright dangerous, I have to downvote your answer. Please do not take it personally. – Markus W Mahlberg Aug 28 '15 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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