[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:
Depends
depends on SERVER-31191 Store the collection UUIDs in the Cat... Closed
is depended on by SERVER-30599 Get shard key into documentKey and re... Closed
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: SERVER-31192 Make Change Stream extract documentKey from insert op log entry
Branch: master
https://github.com/mongodb/mongo/commit/f32371804b610a22fabd7ef8bc726c431c547cf3

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)>catalogCache()>invalidateShardedCollection(nss);

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.

Generated at Thu Feb 08 04:26:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.