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

Upgrade path from 3.6 to 4.0 can leave chunk entries without history on the shards

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • 4.0.27, 4.2.17, 4.4.10, 5.0.5, 5.1.1, 5.2.0-rc1
    • 5.3.0, 5.0.6, 4.2.19, 4.0.29, 5.2.1, 4.4.13
    • Sharding
    • None
    • Fully Compatible
    • ALL
    • v5.2, v5.1, v5.0, v4.4, v4.2, v4.0
    • Sharding EMEA 2021-12-27, Sharding EMEA 2022-01-10
    • 184

    Description

      In 4.0 we introduced support for a multi-version routing table (PM-1013). This later (in 4.2) became the basis for distributed transactions and snapshot reads. As part of this project, we introduced a history field to the persisted chunk type, but we never actually used it in 4.0.

      Since we never used it, the backup/restore procedures ever since 4.0 have referenced that this field is safe do delete on restore. However, it is actually not safe to do so, because it breaks snapshot reads (routing and filtering at a point in time).

      Furthermore, due to the optimisation done under SERVER-53274, we can again have chunks with not history field in the persisted shard-local config.system.cache.chunks collection.

      As a result of the above, we can have 4.0, 4.2, 4.4, 5.0, 5.1, 5.2 clusters which are missing the history fields for some chunks, which in turn breaks snapshot reads and distributed transactions, which will fail with an error saying Chunk has no history entries.

      These clusters will not have any issue functioning, until customers start using distributed transactions and snapshot reads.

      This ticket is to provide manual procedure for restoring the history fields and to implement a command, which will restore the history fields automatically.

      Attachments

        Issue Links

          Activity

            People

              kaloian.manassiev@mongodb.com Kaloian Manassiev
              kaloian.manassiev@mongodb.com Kaloian Manassiev
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: