[SERVER-41093] Primary shard can accept writes for chunk it does not own if _shardsvrShardCollection receives error when writing to config server Created: 10/May/19  Updated: 27/Oct/23  Resolved: 26/Jul/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.3 Desired, 5.0.0

Type: Bug Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Gone away Votes: 0
Labels: pm-1051-legacy-tickets, sharding-causes-bfs-hard
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-34708 Possible for shard to not learn about... Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Participants:
Linked BF Score: 25

 Description   

It's possible during shardCollection for the following to occur
1. _configsvrShardCollection is sent to the config server
2. The config server sends _shardsvrShardCollection to a shard
3. The shard sends an update to the config server to add the collection to the 'config.collections' collection
4. That update succeeds on the config server, but the shard receives some error like NetworkInterfaceExceededTimeLimit, so that it does not hear back from the config server or know whether or not the write succeeded
5. The _shardsvrShardCollection fails, but the config server thinks that collection is sharded, so there's a mismatch between the shard and the config server

If the shard then received an unversioned write to that collection, it would not refresh its routing table, and would treat the collection as unsharded and write the document locally. This could be problematic though, if another write goes through a different router, which does do a refresh from the config server and finds the collection is sharded, and writes data to the correct place.



 Comments   
Comment by Kaloian Manassiev [ 26/Jul/21 ]

As of FCV 5.0, this situation is no longer possible so closing this as 'Gone Away'.

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