[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:
Related
related to SERVER-66869 Get rid of the multi DB locking capab... Closed
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 SERVER-62006, too, so we should double check whether it's a safe use-case: if shardVersion checks aren't relevant, then it should be fine – this is why we should flag guard multi-database locking, to allow it if explicitly declared OK.



 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?

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