[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. 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. |