hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "terry zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9469) Synchronous replication
Date Fri, 28 Feb 2014 03:19:21 GMT

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

terry zhang commented on HBASE-9469:

Hi Feng HongHua, what's about mysql SemiSyncReplication solution? (https://code.google.com/p/google-mysql-tools/wiki/SemiSyncReplicationDesign)
, we need to make sure client write both side is a transaction if you want to data is consistent.

> Synchronous replication
> -----------------------
>                 Key: HBASE-9469
>                 URL: https://issues.apache.org/jira/browse/HBASE-9469
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: 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

View raw message