[
https://issues.apache.org/jira/browse/HBASE-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145918#comment-13145918
]
Lars Hofhansl commented on HBASE-4721:
--------------------------------------
Log based replication won't have any issues with deleted puts, correct.
I'd be worried about tour concerns (2) and (3) above. In HBASE-4536 I spent a
great deal of effort to be able to remove delete markers as soon as possible.
Interestingly HBASE-4536 would not help with the problem you outline. Column
and Version delete markers are version counted (they inherit the version of the
last puts that sorts before them), and eventually removed just like normal puts.
Family delete markers, however, are not sorted in line with puts and are
instead removed during a major compaction if (and only if) there are no puts
that they affect in the file, which leads to the same problem if puts arrive
later during replication, or if the user makes a mistake and places delete
markers in the future.
Do we need to invent a way to undo delete markers?
> Retain Delete Markers after Major Compaction
> --------------------------------------------
>
> Key: HBASE-4721
> URL: https://issues.apache.org/jira/browse/HBASE-4721
> Project: HBase
> Issue Type: New Feature
> Reporter: Prakash Khemani
> Assignee: Prakash Khemani
>
> There is a need to provide long TTLs for delete markers. This is useful when
> replicating hbase logs from one cluster to another. The receiving cluster
> shouldn't compact away the delete markers because the affected key-values
> might still be on the way.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
