I'm facing some issues when trying the following:

  • I have a three-node MongoDB 4.0 cluster, no sharding, one mongodb instance as primary, the rest as secondaries.
  • When I shut down the primary, one of the secondaries becomes the master, the other remains as secondary.
  • When I shut down the new primary (former secondary), the remaining secondary doesn't become master, so the cluster stays inoperative.

I've been following the steps as documentation dictates, so there shouldn't be any configuration steps I forgot.

I even changed the order of creation, but I always get the same result.

What am I doing wrong?

  • 2
    Can you clarify the scenario you are testing? It sounds like you are shutting down two out of three replica set members. The requirement to elect (and maintain) a primary is a strict majority of configured voting members. If you only have one member out of three available, there are no longer enough votes to elect (or maintain) a primary. The majority requirement is to ensure there is only a single primary in a replica set. – Stennie Sep 26 '18 at 21:49

That's normal behaviour. Once the replicaset is down to two members, the voting is even; you need an uneven number of voting members to be able to vote.

The only thing you can do in this case is start that one remaining online mongod as standalone.

| improve this answer | |
  • Thanks for answer but I have two questions: 1 Then way when I have 2 nodes in a replicat set, if I shutdown the primary the secundary becomes in primary. 2 What happens with the cluster and that secundary server, it stays inoperative? becouse the master is the only node where the users can connect for write. – Alejandro Garcia Sep 26 '18 at 15:09
  • The requirement to elect (and maintain) a primary is a strict majority of configured voting members, not an odd number of votes. If you have a replica set configured with three voting members, the strict majority required is two votes. That provides a fault tolerance of 1 (if any member is available, the remaining two voting members can elect a new primary). A member's current state does not change the replica set configuration. – Stennie Sep 26 '18 at 21:42
  • If a majority of replica set members are unavailable, an admin can force reconfigure with surviving members rather than reverting to a standalone config. This should only be done in the event of catastrophic failure, but is a better approach than changing your deployment type. – Stennie Sep 26 '18 at 21:42

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.