[SERVER-31192] Get shard key into documentKey and resumeToken in changeStream 'insert' notification entries Created: 20/Sep/17 Updated: 30/Oct/23 Resolved: 20/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Nathan Myers |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Repl 2017-10-02, Repl 2017-10-23 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
For a sharded collection, DocumentSourceChangeStream requires the shard key in order to extract the shard key from insert entries. When a DocumentSourceChangeStream is constructed, it should store the shard key for the collection. It can get the shard key by calling CatalogCache::getCollectionRoutingInfo(), which will be modified to include the UUID for the collection, to protect against renames. It is important to store the shard key inside DocumentSourceChangeStream, so that it can continue to extract the shard key from insert entries even after the collection has been dropped and the shard key is no longer available in the CatalogCache. Note that if CatalogCache::getCollectionRoutingInfo() returns a mismatched UUID for the namespace, the aggregation should fail. |
| Comments |
| Comment by Githook User [ 20/Oct/17 ] |
|
Author: {'email': 'ncm@cantrip.org', 'name': 'Nathan Myers', 'username': 'ncm'}Message: |
| Comment by Tess Avitabile (Inactive) [ 21/Sep/17 ] |
|
Hmm though we are holding a collection lock when the change stream cursor is first created, right? So I guess we should always succeed after refresh? |
| Comment by Tess Avitabile (Inactive) [ 21/Sep/17 ] |
|
Thanks, Esha. It seems reasonable to me to call CatalogCache::getCollectionRoutingInfo() and if we do not get a return value with the correct UUID, to try CatalogCache::getShardedCollectionRoutingInfoWithRefresh(). |
| Comment by Esha Maharishi (Inactive) [ 20/Sep/17 ] |
|
Instead of mongos sending setShardVersion, we could make the shard invalidate its routing table cache entry for the namespace in the OpObserver for dropCollection: https://github.com/mongodb/mongo/blob/r3.5.13/src/mongo/db/s/collection_sharding_state.cpp#L375-L404 to invalidate the entry, do Grid::get(opCtx) Alternatively there is a CatalogCache::getShardedCollectionRoutingInfoWithRefresh(): https://github.com/mongodb/mongo/blob/r3.5.13/src/mongo/s/catalog_cache.cpp#L195 EDIT: It's not correct to clear the routing table cache entry in the OpObserver for dropCollection, because the shard may refresh its cache before the collection entry is removed from config.collections on the config server. |
| Comment by Esha Maharishi (Inactive) [ 20/Sep/17 ] |
|
Mongos does send setShardVersion after dropping a sharded collection: https://github.com/mongodb/mongo/blob/r3.5.13/src/mongo/s/catalog/sharding_catalog_client_impl.cpp#L551-L568 But it's possible that the setShardVersion won't reach the shard due to, say, a network error. |
| Comment by Tess Avitabile (Inactive) [ 20/Sep/17 ] |
|
I will test this behavior, but CC esha.maharishi, in case she knows off the top of her head. |
| Comment by Spencer Brody (Inactive) [ 20/Sep/17 ] |
|
Do we definitely clear the CatalogCache on collection drops? If so then I think you're right and if the UUID doesn't match we should fail the command. If it doesn't then we should probably try to refresh the cache once to see if it matches once we have the most up to date version. We'll also need to be prepared to load the cache if there's no information in the cache for this collection yet, though that may happen automatically. |