[
https://issues.apache.org/jira/browse/HBASE-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762755#comment-13762755
]
Feng Honghua commented on HBASE-9469:
-------------------------------------
[~lhofhansl] Yes, the better data safety/consistency of synchronous replication
is gotten at the cost of higher latency. Maybe it's more acceptable to make it
per-peer/per-table configurable, let me try to provide a patch accordingly
> Synchronous replication
> -----------------------
>
> Key: HBASE-9469
> URL: https://issues.apache.org/jira/browse/HBASE-9469
> Project: HBase
> Issue Type: New Feature
> Reporter: Feng Honghua
> Priority: Minor
>
> Scenario:
> A/B clusters with master-master replication, client writes to A cluster and A
> pushes all writes to B cluster, and when A cluster is down, client switches
> writing to B cluster.
> But the client's write switch is unsafe due to the replication between A/B is
> asynchronous: a delete to B cluster which aims to delete a put written
> earlier can fail due to that put is written to A cluster and isn't
> successfully pushed to B before A is down. It can be worse if this delete is
> collected(flush and then major compact occurs) before A cluster is up and
> that put is eventually pushed to B, the put won't ever be deleted.
> Can we provide per-table/per-peer synchronous replication which ships the
> according hlog entry of write before responsing write success to client? By
> this we can guarantee the client that all write requests for which he got
> success response when he wrote to A cluster must already have been in B
> cluster as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
