[
https://issues.apache.org/jira/browse/HBASE-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877226#comment-13877226
]
Feng Honghua commented on HBASE-9469:
-------------------------------------
after some rethought, I think this feature has less value than seemingly: if we
response write to caller until the push to peer succeeds, both master/peer
clusters are required to be available, this means from an overall perspective
we just trade-off write availability for read availability but without overall
availability improvement.
on the other hand, such 'synchronous replication' in functionality is almost
equal to letting client write to both clusters, and with worse performance:
client can issue write concurrently to both clusters while synchronous
replication serializes the writes to the two clusters, and additional memory
overhead resulted from duplicate kvs in peer cluster(replication sink plays the
role as a proxy client which receives the push from master cluster and then
write the local cluster as a hbase client, the kvs duplicate in peer cluster
from an overall view)
> Synchronous replication
> -----------------------
>
> Key: HBASE-9469
> URL: https://issues.apache.org/jira/browse/HBASE-9469
> Project: HBase
> Issue Type: New Feature
> Reporter: Feng Honghua
> Assignee: Feng Honghua
>
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)
