[SERVER-30375] make renameCollection attach databaseVersion and shardVersion=UNSHARDED Created: 27/Jul/17  Updated: 30/Oct/23  Resolved: 21/Mar/18

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

Type: Bug Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Kaloian Manassiev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2017-08-21, Sharding 2017-09-11, Sharding 2017-10-02, Sharding 2017-10-23, Sharding 2018-03-26
Participants:

 Description   

renameCollection is not supposed to be allowed to run on sharded collections.

However, today shardCollection and renameCollection can run concurrently, and therefore race.

So, we can end up in a situation where the UUID in a config.collections entry (propagated from the primary shard through shardCollection) differs from the UUID on the primary shard (after renameCollection).

In this case, it is as if the collection has been dropped and recreated as unsharded, but the entry for the old sharded collection doesn't get deleted from config.collections.



 Comments   
Comment by Githook User [ 22/Mar/18 ]

Author:

{'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}

Message: SERVER-33770 SERVER-30375 Make 'convertToCapped' attach databaseVersion and shardVersion=UNSHARDED
Branch: master
https://github.com/mongodb/mongo/commit/d306ed01e21b9c63edb6dc15628ab4f2c0107ef6

Comment by Githook User [ 21/Mar/18 ]

Author:

{'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}

Message: SERVER-30375 Make 'renameCollection' attach databaseVersion and shardVersion=UNSHARDED
Branch: master
https://github.com/mongodb/mongo/commit/bbcff548d0c9922f6dc8f23a4dc8bd02ff9f57fc

Comment by Esha Maharishi (Inactive) [ 08/Mar/18 ]

Assigning to kaloian.manassiev under the "Introduce Database Versioning" project, to make renameCollection attach both shardVersion and databaseVersion.

Comment by Esha Maharishi (Inactive) [ 16/Aug/17 ]

Another way to do this might just be to make renameCollection versioned (i.e., attach ChunkVersion::UNSHARDED()).

Comment by Esha Maharishi (Inactive) [ 27/Jul/17 ]

Marked as "Needs Triage" because it's more Collection Lifecycle-y, and doesn't cause UUID corruption so much as an unreachable collection.

Comment by Esha Maharishi (Inactive) [ 27/Jul/17 ]

Also consider making renameCollection take the same distlock as movePrimary, since otherwise:

1) if user thought both db's were on the same shard, but movePrimary has been called on another mongos: this mongos will accept the rename and send it to the primary shard of the source db.
a) if the source db has moved, the shard will return NamespaceNotFound
b) if the destination db has moved, the db will be re-created on the primary shard of the source db and the collection will be moved into it, leaving the collection unreachable

2) if the user thought both db's were on separate shards, but movePrimary has been called on this mongos: the rename will succeed, perhaps against the user's expectation

Comment by Esha Maharishi (Inactive) [ 27/Jul/17 ]

Marked as "minor" backwards-breaking change, since it will mean renameCollection and shardCollection cannot run concurrently.

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