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

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.0.21
    • Affects Version/s: 4.0.20
    • Component/s: Storage
    • Labels:
    • Fully Compatible
    • ALL
    • Execution Team 2020-10-05

      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.

            gregory.wlodarek@mongodb.com Gregory Wlodarek
            gregory.wlodarek@mongodb.com Gregory Wlodarek
            0 Vote for this issue
            10 Start watching this issue