[SERVER-64121] Add an enum flag to AutoGet* paths that disables multi-database locking unless specifically enabled Created: 02/Mar/22 Updated: 31/May/22 Resolved: 31/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Execution Team 2022-05-02, Execution Team 2022-05-16, Execution Team 2022-05-30, Execution Team 2022-06-13 | ||||||||
| Participants: | |||||||||
| Description |
|
TL;DR: AutoGet* for multi-collection locking cannot correctly ascertain whether collections are unsharded without first having checked the sharding dbVersion. Since AutoGet* relies on secondary namespaces being unsharded, it's only safe to rely on the UNSHARDED response for secondary namespaces that match the primary namespace's database. Because the sharding protocol only supports single collection/db version checking. ------------------------ Kal explained that the UNSHARDED collection version is not reliable without the dbVersion check. The scenario is thus: Shard A is the Primary Shard for database dbfoo. This means all unsharded collections in the database are located on Shard A. An operation on Shard B runs on collection dbbar.bar (primary namespace) and 'dbfoo.foo' (secondary namespace). On Shard B, AutoGet will run a sharding dbVersion check on dbbar, but not on dbfoo; later AutoGet will run a sharding collection shardVersion check on dbfoo.foo that returns UNSHARDED, which is supposed to be safe (note, only unsharded secondary namespaces are supported). Meanwhile, however, dbfoo.foo on Shard A may have become sharded, unbeknownst to Shard B. Basically, UNSHARDED for a collection, without the dbVersion check, can just mean that the Shard that checked the collection isn't participating in holding data for that collection, not that the collection is unsharded. ------------------------ Note: the SBE $lookup multi-collection use-case is on a single database, so that can continue. We did recently use multi-collection locking in |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 03/Mar/22 ] |
|
My thoughts are that there may be situations for internal operations wherein we don't care about sharding checks, and just want multi-collection access because it's easier. At the storage execution layer rather than higher levels. Get the read concern and collection minVisible checks, but disregard sharding. Not certain of the scenario, but there are plenty of places in the code that just take DBLock or CollectionLock, I think, with or without some form of iteratively locking collections. |
| Comment by Kaloian Manassiev [ 03/Mar/22 ] |
|
Instead of adding a flag, shouldn't we just remove the ability in AutoGetDb to pass in more than one database? |