[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: |
|
||||||||||||||||||||||||||||||||||||
| 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: Background: This patch introduces a check for the indices' minimum visible timestamp. (cherry picked from commit a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03) |
| Comment by Githook User [ 14/Sep/22 ] |
|
Author: {'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}Message: Background: This patch introduces a check for the indices' minimum visible timestamp. (cherry picked from commit a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03) |
| Comment by Githook User [ 07/Sep/22 ] |
|
Author: {'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}Message: Background: This patch introduces a check for the indices' minimum visible timestamp. (cherry picked from commit a4bd3ce3607d2c3020d7efa3501240ae4b1a1b03) |
| Comment by Githook User [ 31/Aug/22 ] |
|
Author: {'name': 'Josef Ahmad', 'email': 'josef.ahmad@mongodb.com', 'username': 'josefahmad'}Message: Background: This patch introduces a check for the indices' minimum visible timestamp. |
| Comment by Githook User [ 23/Sep/20 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |
| 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). |