[SERVER-47866] Secondary readers do not need to reacquire PBWM lock if there are catalog conflicts Created: 30/Apr/20  Updated: 29/Oct/23  Resolved: 23/Sep/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.8.0

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-38341 Remove Parallel Batch Writer Mutex Closed
Duplicate
is duplicated by SERVER-49285 Support getMore on snapshot cursor ev... Closed
Related
related to SERVER-67538 Multi-doc transactions should fail if... Closed
related to SERVER-51703 index_secondary_wait_for_commit.js - ... Closed
is related to SERVER-48518 Rollback via refetch (EMRC = false) c... Closed
is related to SERVER-49285 Support getMore on snapshot cursor ev... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2020-09-21, Execution Team 2020-10-05
Participants:
Linked BF Score: 23

 Description   

When a read on a secondary uses kLastApplied/kNoOverlap and encounters a collection catalog conflict, it uses a trick to reacquire the PBWM lock and read without a timestamp.

This was necessary because single-phase background index builds would timestamp writes at future timestamps that may never be seen on secondaries (i.e. "ghost timestamps"). This is not necessary now that simultaneous index builds are the only index builds in 4.5+.



 Comments   
Comment by Githook User [ 28/Sep/22 ]

Author:

{'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}

Message: SERVER-67538 Make multi-doc txns return WCE on index catalog changes

Background: SERVER-47866 stopped bumping the collection's minimum
visibility timestamp on catalog changes related to an index; only the
index's minimum visibility snapshot continues to be updated. One side
effect of this change is that a multi-document transaction can read a
at a snapshot where the index is not yet ready and commit at a
timestamp when the index is ready, which not intended behaviour and
can open the opportunity for a race to happen.

This patch introduces a check for the indices' minimum visible timestamp.
Attempting to write to an index entry while reading at an incompatible
timestamp returns a write conflict exception. Locking rules guarantee that
we see a consistent in-memory view of the indices' minimum visible
snapshot.

(cherry picked from commit a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03)
(cherry picked from commit 4e80712214658e3c70cecef42680618068448e7f)
Branch: v5.0
https://github.com/mongodb/mongo/commit/cbc2fa05af5f8ffe0f2c8f3e37bdd9ac34b3ac85

Comment by Githook User [ 14/Sep/22 ]

Author:

{'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}

Message: SERVER-67538 Make multi-doc txns return WCE on index catalog changes

Background: SERVER-47866 stopped bumping the collection's minimum
visibility timestamp on catalog changes related to an index; only the
index's minimum visibility snapshot continues to be updated. One side
effect of this change is that a multi-document transaction can read a
at a snapshot where the index is not yet ready and commit at a
timestamp when the index is ready, which not intended behaviour and
can open the opportunity for a race to happen.

This patch introduces a check for the indices' minimum visible timestamp.
Attempting to write to an index entry while reading at an incompatible
timestamp returns a write conflict exception. Locking rules guarantee that
we see a consistent in-memory view of the indices' minimum visible
snapshot.

(cherry picked from commit a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03)
Branch: v6.0
https://github.com/mongodb/mongo/commit/899fb0a1adba6b61094cda293a5ed4fa985c5f64

Comment by Githook User [ 07/Sep/22 ]

Author:

{'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}

Message: SERVER-67538 Make multi-doc txns return WCE on index catalog changes

Background: SERVER-47866 stopped bumping the collection's minimum
visibility timestamp on catalog changes related to an index; only the
index's minimum visibility snapshot continues to be updated. One side
effect of this change is that a multi-document transaction can read a
at a snapshot where the index is not yet ready and commit at a
timestamp when the index is ready, which not intended behaviour and
can open the opportunity for a race to happen.

This patch introduces a check for the indices' minimum visible timestamp.
Attempting to write to an index entry while reading at an incompatible
timestamp returns a write conflict exception. Locking rules guarantee that
we see a consistent in-memory view of the indices' minimum visible
snapshot.

(cherry picked from commit a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03)
Branch: v6.1
https://github.com/mongodb/mongo/commit/fd61bf1c3764ee079d3dcde44a2eb24352c22ae5

Comment by Githook User [ 31/Aug/22 ]

Author:

{'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}

Message: SERVER-67538 Make multi-doc txns return WCE on index catalog changes

Background: SERVER-47866 stopped bumping the collection's minimum
visibility timestamp on catalog changes related to an index; only the
index's minimum visibility snapshot continues to be updated. One side
effect of this change is that a multi-document transaction can read a
at a snapshot where the index is not yet ready and commit at a
timestamp when the index is ready, which not intended behaviour and
can open the opportunity for a race to happen.

This patch introduces a check for the indices' minimum visible timestamp.
Attempting to write to an index entry while reading at an incompatible
timestamp returns a write conflict exception. Locking rules guarantee that
we see a consistent in-memory view of the indices' minimum visible
snapshot.
Branch: master
https://github.com/mongodb/mongo/commit/a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03

Comment by Githook User [ 23/Sep/20 ]

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-47866 Secondary readers do not need to reacquire PBWM lock if there are catalog conflicts
Branch: master
https://github.com/mongodb/mongo/commit/669e5650151733738ce8270e5bdf3c5759665316

Comment by Louis Williams [ 10/Sep/20 ]

I ran a patch build experiment here.

It seems like this is possible, but one problem I ran into was that rollback preserves the minVisibleSnapshot from before rollback and reapplies it after rollback. This is a problem because the minVisible for a collection can be further ahead than any lastApplied timestamp. We should explore whether this is still necessary in its current capacity.

Comment by Louis Williams [ 27/May/20 ]

The original description omits the main reason why we do this PBWM "trick". Index builds during initial sync set the collection minimum visible snapshot to the current cluster time.

After initial sync, secondaries readers will get catalog conflicts because the collection minimum visible timestamp is a time that it may never see (in a sharded environment).

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