[
https://issues.apache.org/jira/browse/KUDU-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428466#comment-17428466
]
Andrew Wong commented on KUDU-3326:
-----------------------------------
Thanks for the contribution so far! I do have some questions regarding design,
as well as some thoughts on how I am thinking about them.
*How does this work when a table is trashed and recreated? And then trashed
again before the reservation is complete?*
In this case, it may be worth synchronously deleting the table (and its trashed
data) and creating the table with the same non-trash name. That way, we only
ever have one trashed table at a time, and the first scenario in #5 is
addressed. This runs the risk of losing data if, e.g. the create fails for
whatever reason. But I think that is a reasonable behavior, since the user has
expressed the desire to forget about the old table by creating a new table for
the same name.
*How does this work when HMS-synchronization is enabled? The HMS doesn't allow
for the ":" character. Are trashed tables deleted from the HMS immediately? Or
only when fully deleted?*
When deleting a table, we should still propagate the deletion to the HMS
(rather than a table rename) immediately. Upon recalling the table, we should
recreate the table in the HMS. When performing the {{hms check}} and {{hms
fix}} tools, we should probably ignore trashed tables.
For that matter, for other tools and APIs (list, open table, etc), we may want
to ignore trashed tables as well unless explicitly requested, and ensure the
only thing a user can do with a trashed table is recall it.
> 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
> 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.3.4#803005)
