[SERVER-72488] Consistently handle admin database like config database in sharding Created: 03/Jan/23 Updated: 29/Oct/23 Resolved: 29/Mar/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding NYC
|
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding NYC 2023-02-06, Sharding NYC 2023-02-20, Sharding NYC 2023-04-03 |
| Participants: |
| Description |
|
The config database is treated specially in sharding because it is assumed to be owned by the config server and uses the hardcoded "fixed" database version. To handle this, we have logic that's skipped for the config db, e.g. asserting when asserting a ShardingDDLCoordinator is running on the primary shard for its namespace. Often we only special case the config db, but in theory the admin db should be handled the same way. |
| Comments |
| Comment by Githook User [ 29/Mar/23 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |