cherrypick-1.1: sqlccl: pass needed spans to prev backup checks #19286
Conversation
This file contains 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
Previously we validated previous backups were well-formed and ordered. We did not, however, pass the spans which needed to be covered, the way we do when running the matching check in RESTORE, meaning that we'd accept a set of previous backups that didn't actually cover the spans being backed up. Re-ordering the steps in the backup plan slightly computes the matching tables and spans before validating the prior backups (and setting the start time), thus catching that case where the set of tables (and thus the spans for which we need complete history in order to restore) has changed. Another potential approach would be to automatically change the startTime for the spans for which we are missing history, effectiely de-incrementalizing those tables. This opens up significant additional complexity though. A simple error at BACKUP time should at least indicate there is an issue right away, rather than letting an operator believe they are making usable BACKUPs that cannot actually be RESTOREd.
|
This change is |
bdarnell
approved these changes
Oct 16, 2017
maddyblue
approved these changes
Oct 16, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously we validated previous backups were well-formed and ordered.
We did not, however, pass the spans which needed to be covered, the way we do
when running the matching check in RESTORE, meaning that we'd accept a set of
previous backups that didn't actually cover the spans being backed up.
Re-ordering the steps in the backup plan slightly computes the matching tables
and spans before validating the prior backups (and setting the start time), thus
catching that case where the set of tables (and thus the spans for which we need
complete history in order to restore) has changed.
Another potential approach would be to automatically change the startTime for
the spans for which we are missing history, effectiely de-incrementalizing those
tables. This opens up significant additional complexity though. A simple error
at BACKUP time should at least indicate there is an issue right away, rather
than letting an operator believe they are making usable BACKUPs that cannot
actually be RESTOREd.