-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
Minor Change
-
ALL
-
CAR Team 2026-08-03, CAR Team 2026-08-17, CAR Team 2026-08-31, CAR Team 2026-09-14
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Sharding related collections (like config.shard.catalog.chunks) have been using the single-phase foreground index build, which builds the index first on the primary completely, and then on the standbys after replicating the oplog entry. This is problematic for two reasons:
- if the index build is aborted by a replication rollback, the related catalog entry needs to be patched with an non-timestamped write op, triggering an invariant at WT level;
- Single-phase foreground index builds are not compatible with mongod nodes whose persistence provider supports only primary driven index builds.
- causes
-
SERVER-134440 Add logging for log ingestion when sharding metadata indexes are created on non-empty collections during step up
-
- In Progress
-
- is depended on by
-
SERVER-133532 Ensure synchronous index builds for 'config' namespaces during both node step up and FCV transitions
-
- Closed
-
- is duplicated by
-
SERVER-132958 Config server fasserts on step-up after binary upgrade to 9.0.0-rc1017: aborting the new unique config.shards.uuid_1 index build commits an untimestamped _mdb_catalog write
-
- Closed
-
- related to
-
SERVER-132135 Single-phase foreground index builds write to catalog without timestamp for abort
-
- Backlog
-
-
SERVER-132958 Config server fasserts on step-up after binary upgrade to 9.0.0-rc1017: aborting the new unique config.shards.uuid_1 index build commits an untimestamped _mdb_catalog write
-
- Closed
-
-
SERVER-133532 Ensure synchronous index builds for 'config' namespaces during both node step up and FCV transitions
-
- Closed
-