[backport 3.3] gc: use *.snap st_mtime to schedule after restart#11304
Merged
sergepetrenko merged 1 commit intorelease/3.3from Mar 27, 2025
Merged
[backport 3.3] gc: use *.snap st_mtime to schedule after restart#11304sergepetrenko merged 1 commit intorelease/3.3from
sergepetrenko merged 1 commit intorelease/3.3from
Conversation
Introduce the `timestamp` field in `gc_checkpoint` so now `gc.{c,h}` are
aware of actual times of checkpoints, which is important since this
subsystem is responsible for scheduling. Now, one can track the unix time
of a new checkpoint with new `timestamp` argument of `gc_add_checkpoint`.
This change allows us to track previous checkpoints made before the
server restart and even `checkpoint_interval` value reconfiguring.
This approach was chosen instead of just scanning the `snap_dir` in
`gc.c` because it was engine-independent. One may also notice that even
if the actual time after the last snapshot before the restart is greater
than `2 * checkpoint_interval` we won't start checkpointing immediately
because that may cause high disk load in case of multiple instances. So
in this case we just schedule a checkpoint at a random moment in the
first `checkpoint_interval` seconds after the restart. It seems like
even with this scheduling strategy a snapshot will be eventually created
even during constant restarting.
Fixes #9820
NO_DOC=bugfix
(cherry picked from commit d590c72)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(This PR is a backport of #11074 to
release/3.3to a future3.3.2release.)Introduce the
timestampfield ingc_checkpointso nowgc.{c,h}are aware of actual times of checkpoints, which is important since this subsystem is responsible for scheduling. Now, one can track the unix time of a new checkpoint with newtimestampargument ofgc_add_checkpoint. This change allows us to track previous checkpoints made before the server restart and evencheckpoint_intervalvalue reconfiguring.This approach was chosen instead of just scanning the
snap_diringc.cbecause it was engine-independent. One may also notice that even if the actual time after the last snapshot before the restart is greater than2 * checkpoint_intervalwe won't start checkpointing immediately because that may cause high disk load in case of multiple instances. So in this case we just schedule a checkpoint at a random moment in the firstcheckpoint_intervalseconds after the restart. It seems like even with this scheduling strategy a snapshot will be eventually created even during constant restarting.Fixes #9820
NO_DOC=bugfix