[SERVER-61835] Fix how SBE plan cache deals with ShardFilterer Created: 01/Dec/21 Updated: 10/Jan/24 Resolved: 15/Feb/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.3.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ruoxin Xu | Assignee: | Ruoxin Xu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Sprint: | QO 2022-01-10, QO 2022-01-24, QO 2022-02-07, QO 2022-02-21 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
A ShardFilterer owns a ScopedCollectionFilter which represents a snapshot in time of parts of sharding state. SBE plans make an owned ShardFilterer if needed, and currently the ShardFilterer will be stored together with the SBE plan in the SBE plan cache. Next time when the cached SBE plan is recovered from the cache we could end up using a stale ShardFilterer. This ticket is to investigate whether we should or should not store the ShardFilterer in the SBE plan cache. |
| Comments |
| Comment by Githook User [ 14/Feb/22 ] | |
|
Author: {'name': 'Ruoxin Xu', 'email': 'ruoxin.xu@mongodb.com', 'username': 'RuoxinXu'}Message: | |
| Comment by Anton Korshunov [ 02/Dec/21 ] | |
|
Good call, Ian, yes, we will need to encode the read concern into a plan cache key. | |
| Comment by Ian Boros [ 02/Dec/21 ] | |
|
Another thought I had while reading this, do we account for the read concern in the cache key? If you read with level "available," we don't do shard filtering. So, if you run a query at "available" read concern, we cache that plan and then, a query of the same shape is run with a stronger read concern, is it possible we'd incorrectly use that same plan without the shard filter? | |
| Comment by Anton Korshunov [ 01/Dec/21 ] | |
|
Once plan execution is over the SBE plan will be destroyed releasing all allocated resources, so this shouldn't be an issue. | |
| Comment by Kaloian Manassiev [ 01/Dec/21 ] | |
This sounds like it is more catered towards the first problem that I described above (that the ownership is dynamic and can change). However it will not solve the second problem, which is that range deleter will still be blocked for time proportional to when the next time a plan will be used. Am I understanding it correctly? | |
| Comment by Anton Korshunov [ 01/Dec/21 ] | |
|
kaloian.manassiev jordi.serra-torrens Thanks for your insights, this is very helpful indeed. We have an idea and a draft patch of how this issue can be solved by re-acquiring a ShardFilterer and resetting it on the recovered cached plan before we start executing it, so hopefully this will address your concerns. CC david.storch we may need to prioritize this work after the plan recovery PR gets landed. | |
| Comment by Jordi Serra Torrens [ 01/Dec/21 ] | |
I encountered this problem while working on
| |
| Comment by Kaloian Manassiev [ 01/Dec/21 ] | |
|
If the shard filtering logic is being cached as part of the plan this sounds very wrong, on multiple levels: First of all, the ownership of a shard can change while operations are executing and newer queries should be able to use the most up-to-date filter in order to see the newest changes; Second, holding the filter open blocks range deletion which means that orphan documents will accumulate indefinitely. CC jordi.serra-torrens who I believe hit that problem in testing. |