[SERVER-22572] readConcern majority doesn't consider replica-set changes Created: 11/Feb/16 Updated: 14/Apr/16 Resolved: 27/Mar/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.2.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andrew Ryder (Inactive) | Assignee: | Scott Hernandez (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Repl 11 (03/11/16), Repl 12 (04/01/16) | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
It would appear the only reason to throw away the set of snapshots used for readConcern is if the local node enters ROLLBACK: Replica-set reconfigs would seem to be another way to change the conditions needed to fulfill readConcern majority. For example, in a 5-member replica-set where 2 members are non-voting requires only 2 of the voting members to fulfill a majority readConcern. Reconfig to allow the other 2 members to vote means the set should now demand 3 members to achieve readConcern majority. However, the existing 'verified' snapshot on all members would continue to be used for this purpose despite it (not necessarily) fulfilling the current requirements. |
| Comments |
| Comment by Scott Hernandez (Inactive) [ 27/Mar/16 ] |
|
Snapshots are dropping now, due to changes in |
| Comment by Eric Milkie [ 29/Feb/16 ] |
|
Dropping all snapshots on a reconfig is easy, so to clear up any questions, we will do such. |
| Comment by Eric Milkie [ 11/Feb/16 ] |
|
Another way to think about it is that the read concern level majority view is a view that reflects writes that will never roll back. Since it is possible to have writes reflected in a committed-view snapshot roll back after a reconfig, perhaps we should just drop all snapshots after a reconfig to ensure the integrity of the guarantee. It wouldn't be a hard change to make. |
| Comment by Scott Hernandez (Inactive) [ 11/Feb/16 ] |
|
This sounds more like an enhancement or feature request, not a bug. When the WriteConcern.Majority confirmation for the write was sent to the client it was for a certain configuration, and number representing the "majority". If the config changes, then that will affect future writes, not ones from the past. Since ReadConcern.Majority only ensure your reads were from a previous WriteConcen.Majority point, it sounds like it works exactly the same. ReadConcern.Majority is not about the current "number" of the majority, but about the state of an acknowledged "majority" write, and the configuration at that point. |