-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-27843 If moveAndClose fails HFileArchiver should delete any incomplete archive side changes #5240
Conversation
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
Precommit test failures are not related. The failing tests are related to TLS RPC.
I filed HBASE-27868 for these. |
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.
A minor nits about comments. Overall LGTM.
hbase-server/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java
Show resolved
Hide resolved
hbase-server/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java
Outdated
Show resolved
Hide resolved
…omplete archive side changes When HFiles are placed on a filesystem other than HDFS a rename operation can be a non-atomic file copy operation. It can take a long time to copy a large hfile and if interrupted there may be a partially copied file present at the destination. If we fail to “rename” the files into the archive we will continue to fail indefinitely. Before larger changes are considered, perhaps to StoreFileTracker, we should mitigate this problem.
Addressed review feedback, and rebased. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
…omplete archive side changes (#5240) When HFiles are placed on a filesystem other than HDFS a rename operation can be a non-atomic file copy operation. It can take a long time to copy a large hfile and if interrupted there may be a partially copied file present at the destination. If we fail to “rename” the files into the archive we will continue to fail indefinitely. Before larger changes are considered, perhaps to StoreFileTracker, we should mitigate this problem. Signed-off-by: Duo Zhang <zhangduo@apache.org> Signed-off-by: Viraj Jasani <vjasani@apache.org> Signed-off-by: Wellington Chevreuil <wchevreuil@apache.org> Signed-off-by: Xiaolin Ha <haxiaolin@apache.org>
…omplete archive side changes (#5240) When HFiles are placed on a filesystem other than HDFS a rename operation can be a non-atomic file copy operation. It can take a long time to copy a large hfile and if interrupted there may be a partially copied file present at the destination. If we fail to “rename” the files into the archive we will continue to fail indefinitely. Before larger changes are considered, perhaps to StoreFileTracker, we should mitigate this problem. Signed-off-by: Duo Zhang <zhangduo@apache.org> Signed-off-by: Viraj Jasani <vjasani@apache.org> Signed-off-by: Wellington Chevreuil <wchevreuil@apache.org> Signed-off-by: Xiaolin Ha <haxiaolin@apache.org>
When HFiles are placed on a filesystem other than HDFS a rename operation can be a non-atomic file copy operation. It can take a long time to copy a large hfile and if interrupted there may be a partially copied file present at the destination. If we fail to “rename” the files into the archive we will continue to fail indefinitely. Before larger changes are considered, perhaps to StoreFileTracker, we should mitigate this problem.