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

Bharath Vissapragada commented on HBASE-21856:
----------------------------------------------

Yikes, don't know how I missed that. Thanks for correcting me [~larsh].

I've spent sometime on the current replication internals and design and what 
[~apurtell] suggested (in his first comment) here totally makes sense to me and 
I think thats doable without invasive code changes. This suggested ordering (as 
seen by a sink side for all mutations to a given row must be be causal) is 
critical to a project that I'm working on. So I'd like to assign this to myself 
and give it a shot. Hope thats ok. 

> Consider Causal Replication Ordering
> ------------------------------------
>
>                 Key: HBASE-21856
>                 URL: https://issues.apache.org/jira/browse/HBASE-21856
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: Replication
>            Reporter: Lars Hofhansl
>            Priority: Major
>              Labels: Replication
>
> We've had various efforts to improve the ordering guarantees for HBase 
> replication, most notably Serial Replication.
> I think in many cases guaranteeing a Total Replication Order is not required, 
> but a simpler Causal Replication Order is sufficient.
> Specifically we would guarantee causal ordering for a single Rowkey. Any 
> changes to a Row - Puts, Deletes, etc - would be replicated in the exact 
> order in which they occurred in the source system.
> Unlike total ordering this can be accomplished with only local region server 
> control.
> I don't have a full design in mind, let's discuss here. It should be 
> sufficient to to the following:
> # RegionServers only adopt the replication queues from other RegionServers 
> for regions they (now) own. This requires log splitting for replication.
> # RegionServers ship all edits for queues adopted from other servers before 
> any of their "own" edits are shipped.
> It's probably a bit more involved, but should be much cheaper that the total 
> ordering provided by serial replication.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to