hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4721) Retain Delete Markers after Major Compaction
Date Fri, 11 Nov 2011 20:40:51 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148720#comment-13148720

Todd Lipcon commented on HBASE-4721:

bq. Log based replication won't have any issues with deleted puts, correct.

With the log-based replication as it's currently implemented, we don't have any guarantees
that actions arrive in the same order on the target cluster as they were initiated on the
source cluster, do we? We might have the following sequence:
- region is hosted on server A on source cluster
- A row is put (goes in A's HLog)
- region closes on A, moves to server B
- A now enters a long GC pause, or goes down (before the log shipping got the newest records)
- the row is deleted (goes in B's HLog)
- replication receives the delete from B's HLog before the put from A's HLog

To prevent this, the log-based replication needs to do something to achieve better transactional
ordering when re-applying the edits on the target cluster. Or, we need something like we're
discussing which allows the delete to be retained for some period of time.
> 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


View raw message