consistency/isolation/recency tracking ticket (DOCS-5326)

[DOCS-5324] Document how to use findAndModify with write concern to achieve "quorum read" behavior Created: 30/Apr/15  Updated: 02/Nov/16  Resolved: 14/Jan/16

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: mongodb-3.1.x

Type: Sub-task Priority: Major - P3
Reporter: Andy Schwerin Assignee: Kyle Suarez
Resolution: Done Votes: 0
Labels: 3.2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-17975 Stale reads with WriteConcern Majorit... Closed
Participants:
Days since reply: 7 years, 29 weeks ago

 Description   

Per discussion in the comments of SERVER-17975, in MongoDB systems since at least 2.6, one can use findAndModify with a "w:majority" write concern to perform a read of data that cannot be rolled back and is not stale. We should document this technique for users that require it.

Highlights of the technique:

  1. The findAndModify must use exact match satisfiable with an existing unique index.
  2. The findAndModify must modify some field in the document. I recommend using $inc to increment a field with a name like {{ _dummy_counter_}}.
  3. The write concern used with the findAndModify must be w:majority

Caveats: Not all drivers support findAndModify with write concern.



 Comments   
Comment by Emily Hall [ 27/Jul/16 ]

Closed for housekeeping on 7/27/2016 by Emily Hall.
If you require additional support, please open a new ticket for prioritization.
Thanks,
Emily

Comment by Githook User [ 14/Jan/16 ]

Author:

{u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'kyle.suarez@mongodb.com'}

Message: DOCS-5324 clarify findAndModify quorum read doc

This explicitly details the reasons why one would require a "quorum read" over
the existing majority and local read concerns. It also adds a note warning that
this procedure is much more expensive than a regular read.

This commit also fixes some grammar and explicitly mentions that this technique
is new in MongoDB 3.2.

Signed-off-by: kay <kay.kim@10gen.com>
Branch: master
https://github.com/mongodb/docs/commit/3043f5cd5483a878862342e0431d65e78491e318

Comment by Githook User [ 14/Jan/16 ]

Author:

{u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'kyle.suarez@mongodb.com'}

Message: DOCS-5324 no gle for findAndModify quorum reads

Rather than issuing a getLastError, you can use a write concern of ``majority``
to ensure that findAndModify reads only data that cannot be rolled back.

Signed-off-by: kay <kay.kim@10gen.com>
Branch: master
https://github.com/mongodb/docs/commit/c16563bf83a5883a311b2868aa272643a7b4546f

Comment by Githook User [ 14/Jan/16 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5324 quorum reads with findAndModify

This cherry-picks 046152322b4fae3a98835ed74b718ef7d88f6da2 to apply it again,
undoing the reversion in cf6ab08992633803fa79ee8d8a863200bea435fa.

The changes in source/reference/write-concern.txt have been ignored in favor of
more recent changes.

Signed-off-by: kay <kay.kim@10gen.com>
Branch: master
https://github.com/mongodb/docs/commit/1d060d0dbc451b30c64bd57d1bc07761b85ff51e

Comment by David Golden [ 08/Jan/16 ]

I think you might want to address how this is different than readConcern level:majority.

  • read concern level:majority against a primary ensures data that won't roll back, but it could be stale in a small window of time when the primary is partitioned and hasn't stepped down yet.
  • findAndModify with write concern w:majority can only succeed with a primary that is on the majority side of a partition, thus it ensures that the read is not stale. (The downside being write latency rather than read latency.)

More specifically, the opening paragraph is a bit confusing. I also think it's important to caveat that this technique has a substantial cost over read concern level::majority and should only be used when staleness is absolutely unacceptable.

You have:

When reading from replica sets, in some edge cases, clients can read stale data even when specifying a primary read preference. Clients may also see results of writes before they are made durable and before they have propagated to enough replica set members to avoid rollbacks.

I would phrase it more like this:

When reading from a replica set primary using a local read concern(link), clients may see results of writes before they are made durable and before they have propagated to enough replica set members to avoid rollbacks. This can be prevented by reading from a primary with read concern majority(link). However, even with read concern majority, during a partition it is still possible for a client to read stale data if the primary is on the minority side and has not yet stepped down.

Then the next paragraph opens "This tutorial outlines a procedure..." which directly addresses how I left the opening paragraph.

Then before the "Prerequisites" paragraph is probably the right place to put the caveat about the latency cost of turning a read into a write.

Comment by Eric Milkie [ 04/Jan/16 ]

Rescoped to version 3.2 of the manual only. In version 3.2 it should be possible to use the findAndModify technique as documented.

Comment by Githook User [ 11/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: Revert "DOCS-5324 quorum reads with findAndModify"

This reverts commit 98a314ff56bdec972970f633cdcbc118182bc98c.
Branch: v2.6
https://github.com/mongodb/docs/commit/36b44d72ab52bedc5e67ba8f36ca57c71832cef8

Comment by Githook User [ 11/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: Revert "DOCS-5324 quorum reads with findAndModify"

This reverts commit 046152322b4fae3a98835ed74b718ef7d88f6da2.
Branch: master
https://github.com/mongodb/docs/commit/cf6ab08992633803fa79ee8d8a863200bea435fa

Comment by Githook User [ 11/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: Revert "DOCS-5324 quorum reads with findAndModify"

This reverts commit fc5e1bd7d9081791940a00e538b224db8903653f.
Branch: v2.4
https://github.com/mongodb/docs/commit/f162de8b7bcfc864e28b589ee98d6f48666fed86

Comment by Githook User [ 11/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: Revert "DOCS-5324 quorum reads with findAndModify"

This reverts commit fc5e1bd7d9081791940a00e538b224db8903653f.
Branch: v24
https://github.com/mongodb/docs/commit/f162de8b7bcfc864e28b589ee98d6f48666fed86

Comment by Shannon Bradshaw (Inactive) [ 11/May/15 ]

Raised in the driver leads meeting this morning, "I don't think you can really do this with any driver yet, since both ops have to be on the same socket.". kay.kim@10gen.com let's unpublish this. We need to determine whether any drivers actually support this. If they don't, our proposed solution is misleading.

Comment by Githook User [ 08/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5324 quorum reads with findAndModify
Branch: v2.4
https://github.com/mongodb/docs/commit/fc5e1bd7d9081791940a00e538b224db8903653f

Comment by Githook User [ 08/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5324 quorum reads with findAndModify
Branch: v2.6
https://github.com/mongodb/docs/commit/98a314ff56bdec972970f633cdcbc118182bc98c

Comment by Githook User [ 08/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5324 quorum reads with findAndModify
Branch: v2gs
https://github.com/mongodb/docs/commit/98a314ff56bdec972970f633cdcbc118182bc98c

Comment by Githook User [ 08/May/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5324 quorum reads with findAndModify
Branch: master
https://github.com/mongodb/docs/commit/046152322b4fae3a98835ed74b718ef7d88f6da2

Generated at Thu Feb 08 07:50:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.