HBASE-28919 Soft drop for destructive table actions (branch-2/ branch-2.6) #7184
Conversation
This file contains hidden or 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
Contributor
Author
|
This is the branch-2/branch-2.6 version of #7183 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Although HFiles are copied to the archive in a destructive schema change, recovery scenarios are not automatic and involve some operator labor to reconstruct the table and re-import the archived data. We can easily prevent the deletion of the HFiles of a deleted table or column family by taking a snapshot of the table immediately prior to any destructive schema actions. We also set a TTL on the snapshot so housekeeping of unwanted HFiles remains no touch. Because we take a table snapshot all table structure and metadata is also captured and saved so fast recovery is possible, as either a restore from snapshot, or a clone from snapshot to a new table. Existing site configuration property prerequisites: * hbase.snapshot.enabled = true ( default is true ) New site configuration properties: * hbase.snapshot.before.destructive.action.enabled = true ( default is false ) * hbase.snapshot.before.destructive.action.ttl = <integer>, in seconds ( default 86400 (one day) )
…L as specified in the soft drop design doc. Set the RECOVERY_SNAPSHOT_TTL attribute to override the default site-wide TTL for automatic snapshots created before destructive operations.
apurtell
force-pushed
the
HBASE-28919-2.6
branch
from
d9efb50 to
0aaf32e
Compare
Contributor
Author
|
Rebased, including a piece of the design missed last time, incorporating review feedback. |
|
💔 -1 overall
This message was automatically generated. |
apurtell
force-pushed
the
HBASE-28919-2.6
branch
from
7ee7d3a to
9527a65
Compare
|
🎊 +1 overall
This message was automatically generated. |
Class RecoverySnapshotUtils should be declared as final. [FinalClass]
asf-gitbox-commits
pushed a commit
that referenced
this pull request
Aug 5, 2025
…-2.6) (#7184) Although HFiles are copied to the archive in a destructive schema change, recovery scenarios are not automatic and involve some operator labor to reconstruct the table and re-import the archived data. We can easily prevent the deletion of the HFiles of a deleted table or column family by taking a snapshot of the table immediately prior to any destructive schema actions. We also set a TTL on the snapshot so housekeeping of unwanted HFiles remains no touch. Because we take a table snapshot all table structure and metadata is also captured and saved so fast recovery is possible, as either a restore from snapshot, or a clone from snapshot to a new table. Existing site configuration property prerequisites: * hbase.snapshot.enabled = true ( default is true ) New site configuration properties: * hbase.snapshot.before.destructive.action.enabled = true ( default is false ) * hbase.snapshot.before.destructive.action.ttl = <integer>, in seconds ( default 86400 (one day) ) Signed-off-by: Viraj Jasani <vjasani@apache.org>
|
🎊 +1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
mokai87
pushed a commit
to mokai87/hbase
that referenced
this pull request
Aug 7, 2025
…-2.6) (apache#7184) Although HFiles are copied to the archive in a destructive schema change, recovery scenarios are not automatic and involve some operator labor to reconstruct the table and re-import the archived data. We can easily prevent the deletion of the HFiles of a deleted table or column family by taking a snapshot of the table immediately prior to any destructive schema actions. We also set a TTL on the snapshot so housekeeping of unwanted HFiles remains no touch. Because we take a table snapshot all table structure and metadata is also captured and saved so fast recovery is possible, as either a restore from snapshot, or a clone from snapshot to a new table. Existing site configuration property prerequisites: * hbase.snapshot.enabled = true ( default is true ) New site configuration properties: * hbase.snapshot.before.destructive.action.enabled = true ( default is false ) * hbase.snapshot.before.destructive.action.ttl = <integer>, in seconds ( default 86400 (one day) ) Signed-off-by: Viraj Jasani <vjasani@apache.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Although HFiles are copied to the archive in a destructive schema change, recovery scenarios are not automatic and involve some operator labor to reconstruct the table and re-import the archived data. We can easily prevent the deletion of the HFiles of a deleted table or column family by taking a snapshot of the table immediately prior to any destructive schema actions. We also set a TTL on the snapshot so housekeeping of unwanted HFiles remains no touch. Because we take a table snapshot all table structure and metadata is also captured and saved so fast recovery is possible, as either a restore from snapshot, or a clone from snapshot to a new table.
Existing site configuration property prerequisites:
hbase.snapshot.enabled=true( default istrue)New site configuration properties:
hbase.snapshot.before.destructive.action.enabled=true( default isfalse)hbase.snapshot.before.destructive.action.ttl=<integer>, in seconds ( default86400(one day) )