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

make shards verify that they are present in the config.shards of the cluster their shardIdentity points to



    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Works as Designed
    • Affects Version/s: 3.4.2, 3.5.4
    • Fix Version/s: None
    • Component/s: Sharding
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Sharding 2017-05-08


      While debugging a customer issue with Christopher Harris, we found that it's fairly easy to attempt to make a backup cluster from a snapshot of a production cluster without deleting the shardIdentity doc from the backup shards.

      The backup cluster's shards will have the production cluster's config server connection string in their shardIdentity docs, so they will connect to the production cluster's config servers on startup without complaint. (We want them to instead connect to the backup cluster's config servers).

      It would help in catching this issue if shards were able to verify they were part of config.shards as part of sharding initialization.

      I can imagine this being tricky, though, because it might involve comparing connection strings, which we try to avoid. We can't compare shardIds, because the backup shard and production shard will have the same shardId in their shardIdentity. They will only differ in their host/port.


          Issue Links



              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: