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

Use auto-generated _ids for config.chunks and config.tags

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.3.1
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
    • Fully Compatible
    • Sharding 2019-07-15, Sharding 2019-07-29

      The _id values for documents in config.chunks and config.tags are currently a concatenation of each document’s namespace and minimum bound. Refining a shard key will change the minimum bound, and because _id is immutable, this would require a delete and insert for each document. To allow updating every document in each collection with a single multi-update, the _id values for these documents will be changed to be auto-generated object ids.

      In particular:

      1. Remove all uses of ChunkType::genId() and replace any queries on _id with equivalent queries on ns and min, which should use the existing min_1_ns_1 index.
      2. Store a chunk's _id as a new OID member variable in ChunkType, which corresponds to the existing "name" BSONField
        • e.g. make _id the return value of ChunkType::getName() and allow setting it through ChunkType::setName()
      3. Add a new parser to ChunkType that will not throw if the _id is not found in the given BSONObj and use it in BalanceChunkRequestType::parseFromConfigCommand()
      4. Change moveChunk, mergeChunk, and splitChunk to use the generated _ids of the involved chunks when constructing the updates to config.chunks for their applyOps commands and make splitChunk use OID::gen() to generate _ids for new chunks (necessary because splitChunk uses an upsert to create new chunks)
      5. Replace config.tags queries on _id with equivalent queries on ns and min, which should use the existing min_1_ns_1 index.
      6. Move the logic from ChunkType::genId() to a new method on MigrationType so MigrationType can continue generating its _id by concatenating namespace and min bound.

            jamie.heppenstall@mongodb.com James Heppenstall (Inactive)
            jack.mulrow@mongodb.com Jack Mulrow
            0 Vote for this issue
            3 Start watching this issue