-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Catalog and Routing
-
Fully Compatible
-
Sharding EMEA 2023-10-30, CAR Team 2023-11-13, CAR Team 2023-11-27, CAR Team 2023-12-11, CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22, CAR Team 2024-02-05, CAR Team 2024-02-19, CAR Team 2024-03-04, CAR Team 2024-03-18, CAR Team 2024-04-01, CAR Team 2024-10-14, CAR Team 2024-10-28, CAR Team 2024-11-11
-
2
Currently, users who would like to review the contents of the Sharding config database for debugging purposes can output this database via mongodump (see TOOLS-3374 for an example).
The collections that can/cannot be output have historically been tracked in hardcoded lists in the mongodump code (and similarly for the mongorestore code). A more robust solution moving forward is to have a Sharding API for obtaining this list of collections, to avoid unexpected auth errors like those described in the TOOLS ticket above, and also to ensure that only the necessary debugging collections are included. This list should ideally include only collections that are safe for both mongodump and mongorestore.
When connecting to any Server versions that don't have this API, the tools should continue to use hardcoded lists. To avoid auth errors like in TOOLS-3374, it would be great to exclude the collections known to result in auth errors.
This API should be created with the assumption that power users, e.g., TS, should be able to call it directly (rather than having it be called programmatically by mongodump and mongorestore).
- is depended on by
-
TOOLS-3378 Leverage Sharding API for obtaining collections to dump/restore from config
- Waiting (Blocked)
- related to
-
SERVER-95599 Remove featureFlagConfigDebugDumpSupported after 9.0 becomes lastLTS
- Blocked
-
TOOLS-3444 Include config.placementHistory to the list of collections to be exported/imported for debugging
- Accepted