-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 9.1.0-rc0
-
Component/s: None
-
None
-
Catalog and Routing
-
3
-
🟥 DDL
-
None
-
None
-
None
-
None
-
None
-
None
Problem
collMod can acquire the critical section (block CRUD) if, in addition to the local catalog, it also needs to changes the global and shard authoritative catalog (currently this is only the case for timeseries parameter changes).
Â
However collMod uses the critical section in a way differently than other DDLs:
- config.shard.catalog.collections can be updated outside the CS: On a DB-primary shard without chunks, the critical sections is not acquired, but it receives the update to the shard authoritative catalog anyway.
- The local catalog (mdb_catalog) is updated outside the CS:Â The critical section is released before updating the local catalog.
Â
We believe this is correct but it makes collMod tricky to reason; for example checkMetadataConsistency assumes that "not in critical section implies catalog stability" for delayed secondaries but this is not true for collMod.
Â
Proposed fix
- Always acquire the critical section on the DB-primary shard.
- Do not release the critical section until all global+shard authoritative+local catalog changes are done.
- is related to
-
SERVER-110653 Investigate removing/reducing the CRUD block during granularity changes on timeseries
-
- Closed
-
- related to
-
SERVER-125921 Sharded timeseries collMod can abort without releasing participant critical sections
-
- Closed
-
-
SERVER-132806 checkMetadataConsistency reports spurious CollectionOptionsMismatch during a collMod on a sharded timeseries collection
-
- Closed
-