[
https://issues.apache.org/jira/browse/KUDU-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442039#comment-17442039
]
Andrew Wong commented on KUDU-3326:
-----------------------------------
{quote}Can we add a parameter to decide whether to eliminate (redundant) trash
tables when deleting tables? If so, your elimination method will be very
appropriate. Otherwise, the deletion will fails.{quote}
I guess this is reasonable, to err on the side of less aggressive deletion. So
if we trash table A, then create a new table A, and then trash A before
KUDU_TRASH:A is deleted, the user would be met with an error.
{quote}we can add a parameter to control the number of retained trash
tables{quote}
We can, but how would the naming convention for the multiple trashed tables
work? And if we have multiple trashed tables of the same name, should we be
able to recall any trashed version of a table?
{quote}When HMS-synchronization is enabled，considering that HMS only manages
metadata and has no impact on the timing data of kudu, it can be deleted
directly from HMS. Rebuild it on the HMS during recall.{quote}
Sounds reasonable. I guess we can iron out the HMS features separately, after
the initial patch is merged.
We'll also need to make sure that there's no confusion when listing tables.
E.g. when listing, we shouldn't show any trashed tables unless the user
explicitly asks to include trashed tables in the result.
> Add Soft Delete Table Supports
> ------------------------------
>
> Key: KUDU-3326
> URL: https://issues.apache.org/jira/browse/KUDU-3326
> Project: Kudu
> Issue Type: New Feature
> Components: api, CLI, client, master, test
> Reporter: dengke
> Assignee: dengke
> Priority: Major
>
> h2. Brief description：
> Soft delete means that the kudu system will not delete the table
> immediately after receiving the command to delete the table. Instead, it will
> mark the table and set a validity period. After the validity period, will try
> again to determine whether the table really needs to be deleted.
> This feature can restore data conveniently and timely in the case of
> accidental deletion.
> h2. Relevant modification points：
> 1. After deleting a table, the original table name will be renamed as
> KUDU_TRASHED: < timestamp >: < original table name >, which becomes a trash
> table.
> 2. The contents of the trash table are exactly the same as those of the
> original table. Although it cannot be renamed, added or deleted directly,
> it can be read and written normally. The trash table will be retained for a
> period of time by default (such as 7 days, which can be modified through
> parameters). The compact priority of the trash table will be set to the
> lowest to save the system resources.
> 3. The master needs to add a thread to process expired trash tables and
> perform real deletion.
> 4. It is allowed to create a table with the same name as the original table,
> and the newly created table with the same name can be deleted normally.
> 5. It is allowed to recall deleted tables, but the following two situations
> cannot be recalled: the same original table name exists and the trash table
> has expired.
> 6. The KUDU_TRASHED is a reserved string for the system. Users are not
> allowed to create a table with table names starting with KUDU_TRASHED.
> 7. Kudu tool adaptation soft deletion.
> 8. Java API adaptation soft deletion.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
