[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:
Duplicate
duplicates SERVER-23010 Committed Snapshot Meaning Incorrect Closed
Related
is related to DOCS-7136 Include usage suggestions for ReadCon... Closed
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:
https://github.com/mongodb/mongo/blob/f8dadcefeef7e738d7063ae2df57b9c856b402da/src/mongo/db/repl/replication_coordinator_impl.cpp#L2518

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 SERVER-23010. The behavior you want is now available for the next release.

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.

Generated at Thu Feb 08 04:00:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.