shardCollection/reshardCollection must attempt to create a shardkey when a multikey/wildcard index exists on the shard key field

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: 6.0.26, 8.0.13, 8.3.0-rc0, 7.0.24
    • Component/s: None
    • None
    • Catalog and Routing
    • ALL
    • 1
    • 🟥 DDL
    • None
    • None
    • None
    • None
    • None
    • None

      Problem

      The shardCollection or reshardCollection commands will fail with an InvalidOption error if a multikey or wildcard index exists on the shard key field. However, if a collation, sparse, or filtered index exists on the shard key field, the command will instead implicitly create the shard key index.

       

      Root cause

      This behavior comes directly from the implementation of validShardKeyIndexExists(), which has two checks at different levels that behave inconsistently: one may fail, while the other simply returns true or false.

      In summary, the validShardKeyIndexExsists() will:

      • Return false if the only existing indexes with the shardKey are of type 'collation', 'filter' or 'sparse'.
      • Fail with an InvalidOption if there are indexes that with the shardKey field of type 'multiKey' or 'wildcard'.

      This means that shardCollection or reshardCollection will fail with an InvalidOption error if a multikey or wildcard index exists on the shard key field. However, if a collation, sparse, or filtered index exists on the shard key field, the command will instead implicitly create the shard key index.

       

      Proposal

      The validShardKeyIndexExists() method should stop failing when checkShardingIndex fails, and it should just return false. This change will allow shardCollection and reshardCollection to attempt creating a shard key index even when a multikey or wildcard indexs exist on the shard key field.

       

      How validShardKeyIndexExists() works

      The validShardKeyIndexExists() method performs two main steps:

      • First step. It scans the index specifications to identify potential shard key indexes, filtering out those that are sparse, use collation, or are partial (filter) indexes.
      • Second step. If a potential index is found, it calls the checkShardingIndex command to verify that the index is actually usable. This step detects other incompatibilities, such as multikey or wildcard indexes. If the candidate indexes turn out to be incompatible, the method fails.
      • If no potential shard key index is found in the first step, we just return false.

       

       

            Assignee:
            Unassigned
            Reporter:
            Silvia Surroca
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: