Why do MongoDB docs recommend/insist on specific replica set priority configurations

Question

http://docs.mongodb.org/manual/tutorial/deploy-geographically-distributed-replica-set/

I'm particularly curious as to why they generally want replicas in the non-primary data centre to be priority 0 for elections? If one data centre goes down, I want to be able to failover to (one of) the replica(s) in another data centre. The documentation seems to insist that secondary replicas in a different data centre from the primary should be priority 0, and thusn ineligible for primary status in case of a failure of the "main" data centre. Is this something I can disregard for my needs?

Answer 1

I think you are missing the point here. If you keep the standard configuration with a majority in the primary data center you wont be able to elect new primary if this data center is down even if you set priority to 1.

Lets assume you have configuration like this:

• location A: 2 members with priority 1, arbiter
• location B: 1 member with priority 0
• location C: 1 member with priority 0

Scenarios:

1. Location A down.
   • even if you set priority to 1 for members in data center B and C you won't you wont have majority to elect new primary
2. Location B or C are down
   • rs works as expected
3. Network partition between {A} and {B, C}
   • rs works as expected
4. Non arbiter in data center A is down
   • rs works as expected as long we can communicate with B or C
5. Arbiter and another server from data center is down
   • rs works as expected as long we can communicate with B and C
6. Two non-arbiter members in data center are down, arbiter is up, we can communicate with B and C
   • This is the only problematic case. We have three voting members up but none can become primary

You check that it work similarly for larger clusters.