[
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
