MongoDB | 2637929

Info

The listIndexes command uses different data types for some number fields (e.g. "bits") than what is stored on disk, which can lose precision. The migration recipient currently uses listIndexes to get the indexes the donor has for the collection. This can lead to indexes across shards having slightly different values if the migration would cause the index to be created, or it can lead to unnecessarily failing a migration if an index exists on both shards (because the value for some field but have lost precision and would not compare the same).

Top User Comments

max.hirschhorn@10gen.com commented on Wed, 10 Apr 2024 20:31:55 +0000: I agree it is problematic for chunk migrations to fail due to shards believing they don't have all existing indexes already. My hope is the way we achieve the desired behavior is to rewrite the contents of the local mdb catalog instead. Rewriting the contents of the local mdb catalog is the direction I pushed for in SERVER-77828 to resolve the inconsistencies for the expireAfterSeconds index option which was causing related problems. SERVER-84434 is another manifestation of the listIndexes and createIndexes commands not roundtripping impacting chunk migration. I can imagine systems which are external to the server also depending on listIndexes and createIndexes roundtripping and wouldn't want to use fixing chunk migration directly as a reason to avoid making the necessary general improvements to the local mdb catalog management.

Steps to Reproduce