[
https://issues.apache.org/jira/browse/HBASE-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114463#comment-14114463
]
Gary Helmling commented on HBASE-11292:
---------------------------------------
bq. Yet another way to look at it is: why undelete at all? Ignoring failed
transactions needs to be implemented anyway, so instead of undo one could just
continue to ignore the transaction.
Yes, for the transaction case specifically, that is a fair approach to take.
We can (and do) ignore writes from the failed transaction, but we also need a
way to clear transaction IDs from the invalid set so that it doesn't continue
to grow. This is difficult, but it does need to be solved, regardless of
whether or not we have undeletes. If we can do this efficiently enough, then
there's really no further need to attempt to rollback failed transactions at
all.
However, from the HBase perspective, it has been a long standing issue (or
constraint at least) that deletes cannot be undone. Just ordering operations
by seqid so that you can redo any deleted puts is not a symmetric solution, for
the reasons described above (in the case of a single row delete marker, you
have to rewrite all of the columns in the row).
> Add an "undelete" operation
> ---------------------------
>
> Key: HBASE-11292
> URL: https://issues.apache.org/jira/browse/HBASE-11292
> Project: HBase
> Issue Type: New Feature
> Components: Deletes
> Reporter: Gary Helmling
> Labels: Phoenix
>
> While column families can be configured to keep deleted cells (allowing time
> range queries to still retrieve those cells), deletes are still somewhat
> unique in that they are irreversible operations. Once a delete has been
> issued on a cell, the only way to "undelete" it is to rewrite the data with a
> timestamp newer than the delete.
> The idea here is to add an "undelete" operation, that would make it possible
> to cancel a previous delete. An undelete operation will be similar to a
> delete, in that it will be written as a marker ("tombstone" doesn't seem like
> the right word). The undelete marker, however, will sort prior to a delete
> marker, canceling the effect of any following delete.
> In the absence of a column family configured to KEEP_DELETED_CELLS, we can't
> be sure if a prior delete marker and the effected cells have already been
> garbage collected. In this case (column family not configured with
> KEEP_DELETED_CELLS) it may be necessary for the server to reject undelete
> operations to avoid creating the appearance of a client contact for undeletes
> that can't reliably be honored.
> I think there are additional subtleties of the implementation to be worked
> out, but I'm also interested in a broader discussion of interest in this
> capability.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
