[SERVER-57059] Rename op doesn't bump the collection version Created: 19/May/21  Updated: 19/May/21  Resolved: 19/May/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Sergi Mateo Bellido Assignee: Sergi Mateo Bellido
Resolution: Duplicate Votes: 0
Labels: PM-1965-Cleanup
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-57060 Rename of a sharded collection must b... Closed
Sprint: Sharding EMEA 2021-05-31
Participants:

 Description   

Not bumping the collection version is a problem for scenarios like:

  1. Creation of Collection A
  2. Creation of Collection B
  3. Rename of A to B, dropping target collection.

Assuming that a router saw A and B before the rename, if this router tries to refresh its routing information about B after the rename, this refresh will hang forever.

The underlying problem is that since we didn't bump the collection version, the router thinks that the routing info it has about B is more recent than the one it gets from the config server.

Solution:

We have to bump the collection version. The Collection Version of B after the rename should be newer than the one we had for B before the rename.

  • If we take the conservative approach, this would imply modifying all entries in config.chunks for this collection + its entry on config.collections. Doing that should be enough and it will behave similarly to what we do in refineShardKey. As a drawback we will have to update all chunks associated to the Collection which is something we tried to avoid as much as possible: that's why we replaced the namespaces by uuids, to avoid having to update all chunks.
  • The other approach tries to avoid having to update all docs associated to the collection on config.chunks. Since the replacement of NSS by UUID on config.chunks, we believe that there is no reason to have the epoch and the timestamp on config.chunks. Thus, if we manage to get rid of those, the rename will only have to update config.collections. In order to support backward/forward compatibility we will have to do some minor modifications to the setFCV cmd.


 Comments   
Comment by Sergi Mateo Bellido [ 19/May/21 ]

Jira failed but created the ticket without letting me know

Generated at Thu Feb 08 05:40:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.