[SERVER-47745] Make chunk query in ShardingCatalogManager compatible with chunks created in 3.4 Created: 24/Apr/20  Updated: 29/Oct/23  Resolved: 29/Apr/20

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

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

Issue Links:
Backports
Duplicate
is duplicated by SERVER-45844 UUID shard key values cause failed ch... Closed
Related
is related to SERVER-47744 Include alwayUpsert: false in applyOp... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Sprint: Sharding 2020-05-04
Participants:

 Description   

Prior to 4.4, the _id of each document in config.chunks is the concatenation of its namespace and min bound. It turns out that the string representation of UUID was changed from "BinData(...)" in 3.4 to "UUID(...)" in 3.6. This has led to a couple of backward compatibility issues with the moveChunk, splitChunk, mergeChunk commands for chunks created in 3.4 for collections with UUID shard key. See example 4.0 test here and multiversion test here

  1. The "o2" query in the update oplog entries for all chunk commands is incorrect as it cannot match the target chunks (e.g. the query is { _id: foo.bar-34-x_UUID("fa431a05-70ec-41f3-84f7-b82fc61544d5")} but the target chunk has { _id: foo.bar-34-x_BinData(4, FA431A0570EC41F384F7B82FC61544D5)}). Due to an issue related to alwaysUpsert described in SERVER-47744, the chunks commands always end up failing with DuplicateKey error (if in 3.6, see explanation below).
  2. In 4.0 and 4.2, the moveChunk and splitChunk commands also use _id to look up the chunk to migrate and split. Since these lookups occur before the applyOps, these two commands always fail with IncompatibleShardingMetadata error.

To solve 1, we should do a simpler version of SERVER-42106. where we store _id that was loaded from the config database in ChunkType and use it for oplog entry query. If _id is not present (because the ChunkType object was constructed through other ways), we can just fall back to using genID. To solve 2, we should change the query in _findChunkOnConfig to include just the namespace and minKey just like in 4.4. A multiversion test should be added to test that these chunk operations work for the chunks described above.  



 Comments   
Comment by Githook User [ 29/Apr/20 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'cheahuychou.mao@mongodb.com', 'username': 'cheahuychou'}

Message: SERVER-47745 Make chunk query in ShardingCatalogManager compatible with chunks created in 3.4

(cherry picked from commit 55ea26e1ad7c01038b73551ba483194967567311)
Branch: v4.0
https://github.com/mongodb/mongo/commit/33fc1326ee16fdf01aab21098697551f60fd05bb

Comment by Cheahuychou Mao [ 29/Apr/20 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'cheahuychou.mao@mongodb.com', 'username': 'cheahuychou'}

Message: SERVER-45844 UUID shard key values cause failed chunk migrations
Branch: v4.2
https://github.com/mongodb/mongo/commit/55ea26e1ad7c01038b73551ba483194967567311

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