Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-29604 BackupHFileCleaner uses flawed time based check#7360
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
Uh oh!
There was an error while loading. Please reload this page.
Changes from all commits
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -52,10 +52,13 @@ public class BackupHFileCleaner extends BaseHFileCleanerDelegate implements Abor | ||
| private boolean stopped = false; | ||
| private boolean aborted = false; | ||
| private Connection connection; | ||
| // timestamp of most recent read from backup system table | ||
| private long prevReadFromBackupTbl = 0; | ||
| // timestamp of 2nd most recent read from backup system table | ||
| private long secondPrevReadFromBackupTbl = 0; | ||
| // timestamp of most recent completed cleaning run | ||
| private volatile long previousCleaningCompletionTimestamp = 0; | ||
| @Override | ||
| public void postClean() { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that this definitely looks like an oversight from the original implementation, and that this change corrects it to work as it seems it was originally intended | ||
| previousCleaningCompletionTimestamp = EnvironmentEdgeManager.currentTime(); | ||
| } | ||
| @Override | ||
| public Iterable<FileStatus> getDeletableFiles(Iterable<FileStatus> files) { | ||
| @@ -79,12 +82,12 @@ public Iterable<FileStatus> getDeletableFiles(Iterable<FileStatus> files) { | ||
| return Collections.emptyList(); | ||
| } | ||
| secondPrevReadFromBackupTbl = prevReadFromBackupTbl; | ||
| prevReadFromBackupTbl = EnvironmentEdgeManager.currentTime(); | ||
| // Pin the threshold, we don't want the result to change depending on evaluation time. | ||
| final long recentFileThreshold = previousCleaningCompletionTimestamp; | ||
| return Iterables.filter(files, file -> { | ||
| // If the file is recent, be conservative and wait for one more scan of the bulk loads | ||
| if (file.getModificationTime() > secondPrevReadFromBackupTbl) { | ||
| if (file.getModificationTime() > recentFileThreshold) { | ||
| LOG.debug("Preventing deletion due to timestamp: {}", file.getPath().toString()); | ||
| return false; | ||
| } | ||
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.
So the first run of the chore during the process lifecycle will always do nothing? Is there something else we can base it's initialization value on?
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.
Correct. That was also the (intended, but not actual) behavior of this cleaner before this PR I think.
I guess we can just initialize this to X time before the current time. Could pick X rudimentary, I think a minute is sufficient, or we could set X to the interval in which the cleaner runs, if I trace the code correctly, that would be the value of
hbase.master.cleaner.interval.