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

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



    • Task
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.3.1
    • Sharding
    • None
    • 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.


        Issue Links



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