[
https://issues.apache.org/jira/browse/HBASE-15985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670539#comment-15670539
]
Phil Yang commented on HBASE-15985:
-----------------------------------
Hi,
I just see this issue, sorry for late.
I am wondering what is the real concern for Increment. If I am not wrong, for
Increment, in RS we read the current value and write the sum result to WAL as a
Put. So in replication Increment is same as Put, and "at-least-once delivery"
will not change the value in peer cluster, right?
And for message disordering, we will push timestamp to peer cluster, so the
only concern for Increment is in source cluster there are two Increments done
in same milliseconds, right? For this case I think we can fix it by preventing
using same timestamp from current value to the result.
And we have HBASE-9465 now, we can guarantee the order of pushing if we want.
Although we may push some continuous logs more than once, it will not break
anything because WAL entry is idempotent.
> clarify promises about edits from replication in ref guide
> ----------------------------------------------------------
>
> Key: HBASE-15985
> URL: https://issues.apache.org/jira/browse/HBASE-15985
> Project: HBase
> Issue Type: Sub-task
> Components: documentation, Replication
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Fix For: 2.0.0
>
> Attachments: HBASE-15985.1.patch
>
>
> we should make clear in a call out that replication only provides
> at-least-once delivery and doesn't guarantee ordering so that e.g. folks
> using increments aren't surprised.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
