[ 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