[SERVER-18022] Support "read committed" isolation level where "committed" means confirmed by the voting majority of a replica set Created: 13/Apr/15  Updated: 26/Jul/19  Resolved: 12/Aug/15

Status: Closed
Project: Core Server
Component/s: Querying, Replication
Affects Version/s: None
Fix Version/s: 3.1.7

Type: Improvement Priority: Major - P3
Reporter: Andy Schwerin Assignee: Mathias Stearn
Resolution: Done Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-18999 FindCommand should ignore $-prefixed ... Closed
is depended on by JAVA-2002 Support ReadConcern Closed
is depended on by SERVER-18995 Support reading $readMajorityTemporar... Closed
Related
related to SERVER-42343 WiredTigerLAS.wt grows when lagged no... Closed
related to SERVER-20146 Support readConcern in shell helper d... Closed
is related to DRIVERS-254 Add support for the readConcern option. Closed
Backwards Compatibility: Fully Compatible
Sprint: Quint Iteration 3, Quint Iteration 4, Quint Iteration 5, Quint Iteration 6, Quint Iteration 7, QuInt 8 08/28/15
Participants:

 Description   

Writes in MongoDB replica sets are "committed" when the majority of voting nodes in the replica set confirm the write (n.b., arbiters cannot confirm writes). This ticket is to add a feature to query-like operations (find, count, aggregate, etc) to restrict the data observed to data known to have been committed at the replica set level. It is an approximate but imperfect analog of "w: majority" writes.

In MongoDB deployments using an MVCC storage engine, such as WiredTiger, this behavior could be implemented by having the replication subsystem retain the newest "known committed" version of data on each node, and have the query system serve "committed" reads from that version rather than the newest version.



 Comments   
Comment by Githook User [ 28/Aug/15 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-18022 Fix places relying on old $readMajorityTemporaryName
Branch: master
https://github.com/mongodb/mongo/commit/1eca10057d98aa46e9adf3b06edac74c437edfd3

Comment by Githook User [ 29/Jul/15 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-18022 simplify waiting for first committed snapshot
Branch: master
https://github.com/mongodb/mongo/commit/8b2a3719c3708c97635ddface3f754db0f666f90

Comment by Githook User [ 29/Jun/15 ]

Author:

{u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}

Message: SERVER-18022 Read Majority Committed implementation for primary nodes
Branch: master
https://github.com/mongodb/mongo/commit/28be53c1c9721c4ef8a3046bb3546a1b63e759f6

Comment by Andy Schwerin [ 13/Apr/15 ]

redbeard0531, I finally got around to creating a server ticket for this. Per prior conversation, we'll need to gracefully refuse to support this behavior in storage engines that don't offer the necessary underpinnings.

Generated at Thu Feb 08 03:46:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.