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

on a cluster, allow initiating downgrade (or continuing upgrade) after a failed upgrade and vice versa

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Won't Fix
    • Icon: Major - P3 Major - P3
    • None
    • 3.5.10
    • Sharding
    • None
    • Fully Compatible
    • Sharding 2017-07-31, Sharding 2017-10-23

    Description

      This ticket only deals with the sharding part of upgrade/downgrade (that is, _configsvrSetFeatureCompatibilityVersion), not the upgrade/downgrade on a replica set or single mongod (done through setFeatureCompatibilityVersion).

      The cluster upgrade behavior should already ensure UUIDs are persisted in config.collections for all sharded collections, and that shards' notion of a sharded collection's UUID matches what's in config.collections.

      This ticket is to test this behavior by inducing a failed upgrade (or downgrade), resuming upgrade (or downgrade) or initiating downgrade (or upgrade) afterwards and ensuring the UUIDs across the cluster are consistent.

      Attachments

        Activity

          People

            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: