-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DocDB] PITR: Add flag whether to allow consecutive restores or not #11195
Labels
Comments
sanketkedia
added a commit
that referenced
this issue
Jan 28, 2022
Summary: Commit [fd15c4e](fd15c4e) added the ability to restore to a time older than the completion time of the most recent restoration. This diff disallowes such consecutive restores if the value of the flag `allow_consecutive_restore` is set to false. If the flag is set to true then it will allow the restore to proceed but might break the cluster if the above commit isn't present. Also, fixed a bug wherein we were not currently setting the restoration complete time in case of a restore with 0 tablets. Test Plan: Jenkins Reviewers: bogdan, sergei Reviewed By: sergei Subscribers: ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15020
sanketkedia
added a commit
that referenced
this issue
Jan 29, 2022
…a flag Summary: Commit [fd15c4e](fd15c4e) added the ability to restore to a time older than the completion time of the most recent restoration. This diff disallowes such consecutive restores if the value of the flag `allow_consecutive_restore` is set to false. If the flag is set to true then it will allow the restore to proceed but might break the cluster if the above commit isn't present. Also, fixed a bug wherein we were not currently setting the restoration complete time in case of a restore with 0 tablets. Original commit: D15020 / 293bfb6 Test Plan: Jenkins: rebase: 2.8 Jenkins: urgent Reviewers: sergei, bogdan Reviewed By: bogdan Subscribers: ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15106
sanketkedia
added a commit
that referenced
this issue
Jan 29, 2022
…ded by a flag Summary: Commit [fd15c4e](fd15c4e) added the ability to restore to a time older than the completion time of the most recent restoration. This diff disallowes such consecutive restores if the value of the flag `allow_consecutive_restore` is set to false. If the flag is set to true then it will allow the restore to proceed but might break the cluster if the above commit isn't present. The value of `allow_consecutive_restore` is set to false in 2.6 since the feature isn't present in the branch. Also, fixed a bug wherein we were not currently setting the restoration complete time in case of a restore with 0 tablets. Original commit: D15020 / 293bfb6 Test Plan: Jenkins: rebase: 2.6 Jenkins: urgent Reviewers: sergei, bogdan Reviewed By: bogdan Subscribers: ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15109
sanketkedia
added a commit
that referenced
this issue
Feb 2, 2022
…rded by a flag Summary: Commit [fd15c4e](fd15c4e) added the ability to restore to a time older than the completion time of the most recent restoration. This diff disallowes such consecutive restores if the value of the flag `allow_consecutive_restore` is set to false. If the flag is set to true then it will allow the restore to proceed but might break the cluster if the above commit isn't present. Also, fixed a bug wherein we were not currently setting the restoration complete time in case of a restore with 0 tablets. Original commit : D15020 / 293bfb6 Test Plan: Jenkins Reviewers: sergei, bogdan Reviewed By: bogdan Subscribers: ybase Differential Revision: https://phabricator.dev.yugabyte.com/D15218
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
In commit fd15c4e we added the ability to do a restore to time T1 and then another restore to time T2, where T2 is older than T1. We should add a flag to disallow this completely and just throw an error for the user, in case this logic ends up having issues in the future.
For short term though, such a flag would be a cheap thing to backport to older stable branches, where the initial commit does not cherrypick cleanly.
cc @spolitov
The text was updated successfully, but these errors were encountered: