[SERVER-77837] Locally drop drained databases in transitionToDedicatedConfigServer Created: 06/Jun/23 Updated: 29/Oct/23 Resolved: 12/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0, 7.0.0-rc4 |
| 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 | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Requested: |
v7.0
|
||||||||
| Sprint: | Sharding NYC 2023-06-12 | ||||||||
| Participants: | |||||||||
| Description |
|
After all user data has been moved off the config server and all range deletions have finished, transitionToDedicatedConfigServer will locally drop the drained sharded collections on the config server so it can transition back to config shard mode without user intervention (otherwise the transition back would fail because the empty local collections have the same namespace as the real collections in the cluster). If the user has a sharded view (e.g. a time series collection), there may be system.views collections in the same database as a sharded collection, which currently are not dropped and fail subsequent transitionFromDedicatedConfigServer commands. To avoid this, instead of dropping the drained collections, the config server can locally drop any tracked databases (ie with an entry in config.databases, which cannot include config or admin). |
| Comments |
| Comment by Githook User [ 12/Jun/23 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: (cherry picked from commit 0a55436879bb7e4fa787b3f866201c743092cfbc) |
| Comment by Githook User [ 11/Jun/23 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |