Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-8652

Do not skip the final metadata checkpoint when shutdown configured with use_timestamp=true

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT11.0.0, 6.0.0-rc0, 5.0.15, 4.4.20
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • 5
    • Storage - Ra 2022-02-21
    • v5.3, v5.0, v4.4


      After the final checkpoint as part of the shutdown command, the metadata table is marked as dirty to let it be checkpointed again as part of the dhandle close to avoid the recovery. But the metadata is never checkpointed as part of the dhandle close due to the WT_CONN_CLOSING_TIMESTAMP flag set before the final checkpoint when the connection close is configured with use_timestamp=true.

                   * Mark the metadata dirty so we flush it on close, allowing recovery to be skipped.             
                  WT_WITH_DHANDLE(s, WT_SESSION_META_DHANDLE(s), __wt_tree_modify_set(s));


      Does this affect any team outside of WT?


      How likely is it that this use case or problem will occur?

      Recovery performance improvement

      If the problem does occur, what are the consequences and how severe are they?


      Is this issue urgent?


      Acceptance Criteria (Definition of Done)

       Implement the solution described along with the tests.


      Test scenarios where the logging is disabled/enabled, stable timestamp set/unset and shutdown with use_timestamp options.

      Documentation update


      [Optional] Suggested Solution

      With durable history, there is no remaining data that is left out in the tables that need to be discarded. Allow metadata to be checkpointed as part of the shutdown.

      Allowing metadata checkpoint on dhandle close can cause problems when the database is configured in the following scenario:

      • Open the database with logging disabled
      • Set stable timestamp
      • close the database with use_timestamp=false

      To fix the above problem, mark the metadata dirty only when the logging is enabled. In other scenarios, there is no need to checkpoint metadata again as anyway there is no recovery to be performed.

            ravi.giri@mongodb.com Ravi Giri
            haribabu.kommi@mongodb.com Haribabu Kommi
            0 Vote for this issue
            6 Start watching this issue