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-29255: Integrate backup WAL cleanup logic with the delete command#7007
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
80e65cebdc0de5331ca5186ba7e23655d4873f0e1ce3c24f0File 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 |
|---|---|---|
| @@ -1056,6 +1056,32 @@ public void addContinuousBackupTableSet(Set<TableName> tables, long startTimesta | ||
| } | ||
| } | ||
| /** | ||
| * Updates the system table with the new start timestamps for continuous backup tables. | ||
| * @param tablesToUpdate The set of tables that need their start timestamps updated. | ||
| * @param newStartTimestamp The new start timestamp to be set. | ||
| */ | ||
| public void updateContinuousBackupTableSet(Set<TableName> tablesToUpdate, long newStartTimestamp) | ||
| throws IOException { | ||
| if (tablesToUpdate == null || tablesToUpdate.isEmpty()) { | ||
| LOG.warn("No tables provided for updating start timestamps."); | ||
| return; | ||
| } | ||
| try (Table table = connection.getTable(tableName)) { | ||
Contributor 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. NIT: Add a null check for tablesToUpdate | ||
| Put put = new Put(rowkey(CONTINUOUS_BACKUP_SET)); | ||
| for (TableName tableName : tablesToUpdate) { | ||
| put.addColumn(BackupSystemTable.META_FAMILY, Bytes.toBytes(tableName.getNameAsString()), | ||
| Bytes.toBytes(newStartTimestamp)); | ||
| } | ||
| table.put(put); | ||
| LOG.info("Successfully updated start timestamps for {} tables in the backup system table.", | ||
| tablesToUpdate.size()); | ||
| } | ||
| } | ||
| /** | ||
| * Removes tables from the global continuous backup set. Only removes entries that currently exist | ||
| * in the backup system table. | ||
Uh oh!
There was an error while loading. Please reload this page.
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.
If there is an api to delete in batches, we should use it. Also based on the nos of the file you are deleting this method can take lot of time. May be we can asynchronous here. Please give a thought
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.
Yeah, I checked but couldn’t find any API that supports batch deletion.
About going async — it’s a good idea, but it might add some complexity. We’d need to track if the delete actually finished, retry on failure, and maybe notify the user when it’s done.
So we should probably think about whether the added complexity is worth the gain. Also, right now, all our backup and restore commands (like full backup, incremental, restore) are synchronous anyway, and those can take hours.
I think async is definitely a good direction — just that it probably makes sense to build a proper framework around it first, so we can handle retries, tracking, and notifications across the board. What do you think?
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.
Lets build a job co-ordinator framework with zookeeper. We should build that outside the scope of this ticket off course.
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.
Sure, let me create a jira for that.
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.
Good point guys, but before going down this rabbit hole, please do some performance tests for justification. Try to delete 100, 10000 and 1 million files in a single directory and share how much time does it take synchronously. Delete/unlink operations should be relatively quick in any filesystem, but let's see how it works with S3.