-
Type: Investigation
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Not Needed
By tracking unsharded collections in the catalog we're exposing more collections in the config server. Automated processes that capture collection information from the config server or other means may now capture information on unsharded collections
We'll be adding and removing information about the from various commands to improve the user experience
Description of Linked Ticket
Summary
This project is about starting to track unsharded collections metadata in the sharding catalog.
Motivation
The sharding catalog is currently tracking only sharded collections on the config server while unsharded collections are simply locally tracked by the owning shards. This misalignment results in having to handle metadata differently based on whether a collection is sharded or not, de-facto limiting the possibility of having a unified/reusable machinery.
This project targets the following issues:
Engineers having to deal with both sharded and unsharded collections is a drag on productivity because of the need to constantly work around it.
Users want to be able to move unsharded collections across their cluster and this is a preliminary step to allow that.
Documentation
Product Description
Scope
Technical Design
Docs Update
- related to
-
MONGOSH-1706 Account for unsharded collections becoming part of the sharding catalog
- Closed
-
MONGOSH-1328 db.collection.getShardDistribution() should give a warning rather than report collection is not sharded
- Closed