-
Type: Bug
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: 5.0.0
-
Component/s: Sharding
-
ALL
-
v5.0
-
Sharding EMEA 2021-05-31, Sharding EMEA 2021-11-01
-
2
As of now, it's possible that the contents of config.tags can be changed in-between the time at which config.tags is queried, and when the final set of requested zones is written to the temporary collection. There are a couple of concurrency constraints that can be used, one which seems necessary, and the other which may be necessary but would require additional thought.
- It will be necessary to safeguard allowing zone operations (any operations that takes _kZoneOpLock) such that when the collection entry's allowMigrations flag is set to false, zone operations cannot be completed either. This brings up a few questions you might want to answer:
- Is the name allowMigrations okay to use for zone operations?
- Is it okay to piggyback off this flag instead of creating a new flag?
- Also consider taking the _kZoneOpLock while querying config.tags. From back-of-the-napkin thinking, it seems like if the config.tags query comes after setting the collection entry's flag, then taking this lock won't be necessary.
- related to
-
SERVER-73763 Resharding does not extend zone ranges for config.tag docs, leading to config server primary fassert loop from duplicate key error
- Closed
-
SERVER-73848 Hashed shard keys with zones can cause issues with resharding
- Closed
-
SERVER-56799 Use temporary namespace when writing tags docs for zones passed to resharding command
- Closed