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

[v4.0] fsyncLock must not take a stable checkpoint when majority read concern is off

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.0.20
    • Fix Version/s: 4.0.21
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Execution Team 2020-10-05
    • Case:

      Description

      When majority read concern is off, we take unstable checkpoints ("use_timestamp=false") in the checkpoint thread. This prevents the checkpoint_timestamp entry from appearing in the WiredTiger.backup file to properly restore a WiredTiger backup taken via filesystem copies.

      However, when the fsyncLock command is run, it takes a checkpoint after locking the instance. A checkpoint is taken with "use_timestamp=true", which is a stable checkpoint and includes the checkpoint_timestamp entry in the WiredTiger.backup file. This is not the desired behaviour and overwrites the correct setting chosen earlier by the checkpointing thread.

       

      fsyncLock calls WiredTigerKVEngine::flushAllFiles with stableCheckpoint = true. When stableCheckpoint is true, we take a stable checkpoint. This needs to be changed to take an unstable checkpoint when majority read concern is off.

       

      This problem went away in v4.2 and later versions from the work done in SERVER-37897.

        Attachments

          Activity

            People

            Assignee:
            gregory.wlodarek Gregory Wlodarek
            Reporter:
            gregory.wlodarek Gregory Wlodarek
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: