[SERVER-8829] String representation for chunk id is not unique Created: 02/Mar/13  Updated: 06/Dec/22  Resolved: 09/Aug/19

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

Type: Bug Priority: Major - P3
Reporter: Greg Studer Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File bindata_sharding.js     File upgrade_cluster_v3_to_v4_wait_for_mongos.js    
Issue Links:
Depends
is depended on by SERVER-14759 Splitting very close to an existing d... Closed
Duplicate
duplicates SERVER-4411 creating a migration lock on the seri... Closed
duplicates SERVER-42106 Use auto-generated _ids for config.ch... Closed
is duplicated by SERVER-8787 mongos crashing when running splits +... Closed
is duplicated by SERVER-40061 Chunk move fails due to DuplicateKey ... Closed
Related
related to SERVER-27734 Remove the _id field from config.chun... Closed
related to SERVER-27735 Remove uses of config.chunks' _id field Closed
Assigned Teams:
Sharding
Operating System: ALL
Participants:

 Description   

... in particular, certain numbers (numberlong, numberint) have the same representation as a string in BSON. This leads to duplicate key errors when generating chunk ids based off these values.

see SERVER-8787



 Comments   
Comment by Kaloian Manassiev [ 09/Aug/19 ]

Starting in MongoDB 4.3, this is no longer an issue, because the _id fields of the chunks collection have been converted to be auto-generated.

Comment by Greg Studer [ 29/May/13 ]

Just to clarify, this bug is present in all releases of mongodb, however it is somewhat simpler to trigger using hashed shard keys (though still very rare in the wild) since int(0) and long(0) have the same string representation. Symptoms would be a hole in the chunks collection after a split or initial split, resulting in the collection becoming unusable (though the data itself is unaffected).

The workaround is simply to be consistent with types in shard keys. We do sanity checks before splits which should detect many cases as well. Any full fix will not be backportable.

Comment by Greg Studer [ 04/Mar/13 ]

Attached test reproduces problem on any 2.4, all mongo versions probably affected though.

Generated at Thu Feb 08 03:18:34 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.