[
https://issues.apache.org/jira/browse/HBASE-21856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926815#comment-16926815
]
Andrew Purtell commented on HBASE-21856:
----------------------------------------
The *_source_* must ship all regions to the same sink regionserver. That is the
narrowest requirement on the source side. All edits for a region must flow to
the same sink, presumably selected with a consistent hash. The *_sink_*
regionserver must then apply the batches in order. It is not strictly necessary
for the source to send batches sequentially or in a blocking manner. We might
opt to implement it that way, but it is not necessary. IMHO, better to do the
mastering and ordering on the sink side, but agree it may make implementation
more challenging.
> 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.2#803003)
