[SERVER-3668] Don't allow more than one arbiter per replica set Created: 22/Aug/11  Updated: 24/Aug/12  Resolved: 22/Aug/11

Status: Closed
Project: Core Server
Component/s: Replication, Usability
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Mathias Stearn Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

I've seen users and multiple arbiters "just to be safe". I think the idea is that if one is good than more is better. It often results in returning the set to an even number of members which defeats the purpose of the arbiter. Unless there is a good reason to allow more than one, we should disallow it to keep users from shooting themselves in the foot.



 Comments   
Comment by mark nielsen [ 24/Aug/12 ]

Sorry to be harsh, but kill this idea.

I had a primary that could not go down.
Sometimes you need two arbiters temporarily.
Take one primary, one secondary, and one arbiter.
The system doesn't need two secondaries, though I know its better if you do.

If you need to move an arbiter, during that move, if the secondary goes down, the primary will go to read-only because the replica set is down, the arbiter and secondary are both down.

Thus, you add and 2nd arbiter, before you remove the 1st.

There was another case, I forget the details, where we needed 2 temporary arbiters.

"Should never allow" is harsh. I think you should be able to shoot yourself in the foot if you really want.

Comment by Kristina Chodorow (Inactive) [ 22/Aug/11 ]

What do you mean by "the most connected data center"?

Comment by Eliot Horowitz (Inactive) [ 22/Aug/11 ]

There are many.
Think about the case where you want the most connected datacenter to be active

Generated at Thu Feb 08 03:03:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.