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

Andrew Purtell edited comment on HBASE-21856 at 9/19/19 9:23 AM:
-----------------------------------------------------------------

The sender is going to be providing batches in sequence to each consistent 
target. These batches may arrive out of order but the window will be small by 
definition because RPCs are in flight when the ordering can be indeterminate. 

But if we are having issues as described if we introduce a back pressure signal 
or retransmit indication that stops the sender, or causes it to (exponentially) 
back off, or causes it to resend a specific batch, this could be explored - but 
only if actually needed


was (Author: apurtell):
That's correct. But if we are having issues as described if we introduce a back 
pressure signal that stops the sender, or causes it to (exponentially) back 
off, this will be fine. 

> 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