[SERVER-9589] semi-automatic new primary election / graceful shutdown of replica sets Created: 06/May/13 Updated: 06/Dec/22 Resolved: 23/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Admin, Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Vincent Sevel | Assignee: | Backlog - Replication Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | elections | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
for environments that cannot afford a risk of data loss or inconsistency (ie: that would prefer unavailability instead), the arbiter could provide a mode where the election of a new primary is allowed only if are absolutely sure that there is an up to date node in the replica set. this guarantee can be offered if the primary has been shut down gracefull, but not in the case of a crash.
that way, we have:
|
| Comments |
| Comment by Spencer Brody (Inactive) [ 23/Aug/18 ] |
|
This can be accomplished with a two node replica set or by manipulating the number of 'votes' assigned to nodes in the replica set config. |
| Comment by Vincent Sevel [ 14/May/13 ] |
|
if the primary crashes, the secondary will become primary no matter how late it was in its replication, and the application will be immediately available serving stale data.
|
| Comment by Eliot Horowitz (Inactive) [ 14/May/13 ] |
|
I think stepDown already does what you want. |