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

Add versioning scheme to the KVCatalog to handle upgrade/downgrade with new 3.4 features

    • Fully Compatible
    • Query 13 (04/22/16), Query 14 (05/13/16), Query 15 (06/03/16)

      The KVCatalog::FeatureTracker manages a document in the KVCatalog of the following form

      {
          isFeatureDoc:  true,
          ns:            null,
          repairable:    0b0000...0000,  // 64 bits
          nonRepairable: 0b0000...0000,  // 64 bits
      }
      

      The "ns" field has a value of null in order to make calls to obj["ns"].String() in KVCatalog::init() massert on versions of MongoDB earlier than the fixVersion of SERVER-23117.

      A version of mongod will fail to start up if an unrecognized feature is marked as in-use on the data files. This allows a breaking change to be made between two major versions of MongoDB and require users to downgrade to a newer version of the older major release in order to be able to downgrade cleanly. The feature document is inserted into the KVCatalog only after the first feature is enabled on the data files, e.g. the feature document will be inserted when a new index is created after upgrading to 3.4 (SERVER-24095).

      The distinction between the "repairable" and "nonRepairable" feature bits is that special handling (SERVER-24097) could be done for the "repairable" feature bits when the mongod is started with --repair, e.g. if the feature only affects indexes and not collection data.

            Assignee:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: