[SERVER-64542] shardCollection no-op oplog can be written even when command ultimately fails Created: 15/Mar/22  Updated: 29/Oct/23  Resolved: 18/Mar/22

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

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Randolph Tan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-61887 Add a no-op oplog entry for shardColl... Closed
is related to SERVER-6491 Prevent dropping shard key index when... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding NYC 2022-03-21
Participants:

 Description   

Currently, we write the oplog right before we send the final update that commits the migration to the config server:

https://github.com/mongodb/mongo/blob/077b55e6330264b262d87d296a7f7006fece669e/src/mongo/db/s/create_collection_coordinator.cpp#L920

However, if the server restarts right before the final update it sent, then it is possible for dropIndex to sneak in and drop the necessary index required by the shard collection. When the CreateCoordinator gets restored and tries to redo, it will find out that the collection doesn't have the required index for the shard key pattern and fail.

Some context for why oplog was written before the final update: it was done to achieve the property where the oplog will have ts < any writes that come after the collection became sharded.



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

Author:

{'name': 'Randolph Tan', 'email': 'randolph@10gen.com', 'username': 'renctan'}

Message: SERVER-64542 shardCollection no-op oplog can be written even when command ultimately fails
Branch: master
https://github.com/mongodb/mongo/commit/25ddbc88cabaf0d14896c40526dc1b7a3077aebe

Generated at Thu Feb 08 06:00:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.