[SERVER-29701] Split PRIMARY replset state into PRIMARY and PRIMARY_ELECT Created: 16/Jun/17 Updated: 06/Dec/22 Resolved: 07/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
When a newly elected primary is in catchup or drain mode, it can't actually take writes. This can be observed by running the isMaster command against the primary and observing that it returns ismaster:false in its response, but that still leaves every other place that just shows the replica set state (i.e. replSetGetStatus, many log messages, MMS monitoring, etc) as just reporting PRIMARY. To make it clear the difference between a primary that can and can't yet take writes, nodes should report themselves as PRIMARY_ELECT until they have fully completed catchup and drain modes and are available for writes. |
| Comments |
| Comment by Steven Vannelli [ 07/Oct/19 ] |
|
Closing this ticket as Won't Do as the parent Epic is no longer needed at this time. |
| Comment by Spencer Brody (Inactive) [ 16/Jun/17 ] |
|
This is likely to have impact on downstream teams, such as cloud/ops manager which will need to start understanding the new state. |