[SERVER-55781] Verify shard version matches before allowing createIndexes in sharding opObserver Created: 05/Apr/21 Updated: 29/Oct/23 Resolved: 20/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | Marcos José Grillo Ramirez |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Backport Requested: |
v5.0
|
||||||||||||||||||||||||
| Sprint: | Sharding EMEA 2021-05-17, Sharding EMEA 2021-05-31 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 197 | ||||||||||||||||||||||||
| Description |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] | ||||||||||||||||
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! | ||||||||||||||||
| Comment by Githook User [ 20/May/21 ] | ||||||||||||||||
|
Author: {'name': 'Marcos Jose Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}Message: (cherry picked from commit 7feb0ddaae387ea1720a2bee53f1e57a756dd359) | ||||||||||||||||
| Comment by Githook User [ 20/May/21 ] | ||||||||||||||||
|
Author: {'name': 'Marcos Jose Grillo Ramirez', 'email': 'marcos.grillo@mongodb.com', 'username': 'm4nti5'}Message: | ||||||||||||||||
| Comment by Marcos José Grillo Ramirez [ 03/May/21 ] | ||||||||||||||||
|
After talking to blake.oler I'm going to refine a bit the bf_repro.js to add a create collection and ensuring that the shard where the create indexes command failed with the transient error is not the primary shard, that way we can check at the end that the UUID of the collections are different among the shards. | ||||||||||||||||
| Comment by Marcos José Grillo Ramirez [ 30/Apr/21 ] | ||||||||||||||||
|
To answer the open question, yes, the collection creation is rollbacked if we throw from the shard op observer. From doing some local tests and reading the code, the procedure to create indexes on an empty unsharded collection first creates the collection implicitly, and then create the indexes, but given the fact that this is being done under a WriteUnitOfWork if we never reach the commit then everything is rollbacked. | ||||||||||||||||
| Comment by Max Hirschhorn [ 07/Apr/21 ] | ||||||||||||||||
Dropping the collection locally on the shard with assertDropCollection() is slightly different from what happens during resharding. This is because, in resharding, dropping the collection locally on the donor shard was accompanied by an update to the collection metadata to say that the donor shard no longer owns chunks for the collection being dropped. ShardingTest#checkUUIDsConsistentAcrossCluster() fails in bf_repro.js However, the createIndexes command is still implicitly creating a new collection in the collection catalog. This is undesirable because it would lead a future chunk migration into this shard to fail. These extraneous collections are not new in sharding (see
| ||||||||||||||||
| Comment by Blake Oler [ 05/Apr/21 ] | ||||||||||||||||
|
Attached is the bf repro jsTest, along with the diff in create_indexes.cpp that simulates a StaleConfigException. |