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

Poke WT oplog reclamation thread periodically

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.3.0-rc0, 7.0.5, 6.0.13, 5.0.24
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Storage Execution
    • Fully Compatible
    • v7.0, v6.0, v5.0
    • Execution Team 2023-11-13, Execution Team 2023-11-27

      Currently we only perform checks (in the oplog reclamation thread) as to whether the WT oplog can be truncated when a) we finish sampling the oplog during recovery, b) we resize the oplog, or c) we create a new oplog stone.

      In cases where the oplog size exceeds the limit, but the oplog window is smaller than the configured retention period, we may (correctly) choose not to truncate the oplog at a given point in time. However, if enough time passes so that the oplog window grows, but one of the three triggering events described above does not occur, we currently will not truncate the oplog. For instance, during a long period of low write activity, we may not generate a new oplog stone, leaving the oplog untruncated for a long period of time.

            daotang.yang@mongodb.com Daotang Yang
            dan.larkin-york@mongodb.com Dan Larkin-York
            0 Vote for this issue
            10 Start watching this issue