hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15985) clarify promises about edits from replication in ref guide
Date Wed, 16 Nov 2016 14:27:58 GMT

    [ 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:

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

View raw message