Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-6832

sharding on prefix doesn't trigger "move top chunk" heuristic and causes assertion 10367

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor - P4
    • Resolution: Fixed
    • Affects Version/s: 2.2.0-rc1
    • Fix Version/s: 2.2.1, 2.3.0
    • Component/s: Indexing, Sharding
    • Labels:
      None
    • Operating System:
      ALL

      Description

      Sharding on a key that's a prefix of an existing index can leave assertions in the logs that look like:

       m30001| Wed Aug 22 22:00:27 [conn4] assertion 10367 no index found for specified keyPattern: {} min: { a: 0.0 } max: { a: MaxKey } ns:test.foo query:{ query: {}, $min: { a: 0.0 }, $max: { a: MaxKey } }

      The source of these assertions is a query made at the end of the "splitChunk" command. The query errors because it assumes the existence of an index that's an exact match for the shard key. The query is only used to decide whether to append the "shouldMigrate" flag to the result of the command, which in turn is used as some sort of heuristic by Chunk::splitIfShould() to decide which chunk to move after the split. Leaving out the "shouldMigrate" flag does not appear to affect correctness. I suspect this heuristic is rarely triggered anyway. However because of this issue, using a prefix shard key may yield slightly different behavior than a shard key with an exact index match.

      Test attached which shows the assertions.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: