Skip to content
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

Closed
bmatican opened this issue Jan 24, 2022 · 0 comments
Closed

[DocDB] PITR: Add flag whether to allow consecutive restores or not #11195

bmatican opened this issue Jan 24, 2022 · 0 comments
Assignees
Labels
area/docdb YugabyteDB core features priority/high High Priority

Comments

@bmatican
Copy link
Contributor

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

@bmatican bmatican added the area/docdb YugabyteDB core features label Jan 24, 2022
@bmatican bmatican added this to Backlog in YBase features via automation Jan 24, 2022
@bmatican bmatican added the priority/high High Priority label Jan 24, 2022
@bmatican bmatican added this to To do in PITR via automation Jan 24, 2022
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
@bmatican bmatican closed this as completed Feb 3, 2022
YBase features automation moved this from Backlog to Done Feb 3, 2022
PITR automation moved this from To do to Done Feb 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features priority/high High Priority
Projects
PITR
Done
Development

No branches or pull requests

2 participants