-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
backupccl: backup correctly tries reading in from base directory if l… #77315
Conversation
Didn't do too much testing since it was getting late, but basically I just went with the first easier solution (where we just always try reading from base directory on error) just to confirm that it was indeed the problem. Just running a few tests it seemed like it didn't break anything and the original issue seemed fixed. But i'll give it some more testing tomorrow and figure out what solution we want to go with. |
de639be
to
e8a56ac
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. Would it be possible to write a unit test that blocks the cluster from upgrading past the BackupDoesNotOverwriteLatestAndCheckpoint
version, taking a backup, then allowing it to upgrade, and running an incremental on the same chain?
latestFile, err = exportStore.ReadFile(ctx, latestFileName) | ||
if err != nil { | ||
return nil, errors.Wrap(err, "Latest file could not be read in base or metadata directory") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: s/Latest/LATEST/g
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't 100% sure what you meant by this, did you mean in place of "latest file" or the "metadata directory"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh just change Latest
to LATEST
since thats the sentinel file name we use.
bbd7020
to
29ae66d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still like to see the test we discussed earlier in this PR, but happy to do that as a fast follow.
29ae66d
to
1bff87f
Compare
…atest/checkpoint files aren't found Before, we only tried reading from the base directory if we caught a ErrFileDoesNotExist error. However this does not account for the potential error thrown when the progress/latest directories don't exist. This changes it so we now correctly retry reading from the base directory. We also put the latest directory inside of a metadata directory, in order to avoid any potential conflicts with there being a latest file and latest directory in the same base directory. Also wraps errors in findLatestFile and readLatestCheckpointFile for more clarity when both base and latest/progress directories fail to read. Fixes cockroachdb#77312 Release justification: Bug fix for release blocker Release note: none
1bff87f
to
c9e9855
Compare
bors r+ |
Build succeeded: |
…atest/checkpoint files aren't found
Before, we only tried reading from the base directory if we caught a ErrFileDoesNotExist error. However
this does not account for the potential error thrown when the progress/latest directories don't exist.
This changes it so we now correctly retry reading from the base directory.
We also put the latest directory inside of a metadata directory, in order to avoid any potential
conflicts with there being a latest file and latest directory in the same base directory.
Also wraps errors in findLatestFile and readLatestCheckpointFile for more clarity when both base and
latest/progress directories fail to read.
Fixes #77312
Epic CRDB-7586
Release justification: Low risk bug fix
Release note: none