hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-9934) Mesh replication (a.k.a. multi master replication)
Date Mon, 11 Nov 2013 22:44:18 GMT

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

Lars Hofhansl edited comment on HBASE-9934 at 11/11/13 10:43 PM:
-----------------------------------------------------------------

I agree. 

Let me setup a graph of HBase clusters for further discussion. Lets say we have 6 clusters,
C1..C6.
C1..C3 want to replicate to each other in the NxN fashion (i.e. with no forwarding) and the
following master master replications are setup: C4 <\-> C3, C5 <\-> C3 and C6
<-> C5

C4 <\-> C3 <\-> C5 <-> C6
           /    \
        C1 - C2

1. The source cluster sets the replication scope for the column family that is being replicated
as SINGLE_HOP_ONLY and the targets clusters do not forward KeyValues with families that have
their scope set as this. The decision on whether a write should be forwarded ahead thus lies
with the source cluster in this case. This will work if we just had C1..C3 but will *not*
work in the above example since a write from C4 will not have the correct scope set and will
circulate more in C1..C3 than needed. We could say that such a mixed setting is not supported,
but it is hard to prevent someone from shooting themselves in their foot.

2.  Having thought about this, this looks more like a property of the link (whether it is
a part of mesh network or a standard Master-Slave / Master-Master link). If a link is a part
of the mesh network, then *all* writes coming from that link (including ones that could have
originated at a different cluster) should not be forwarded. To do this setup, we would have
to add this as a property for the peer (in the zookeeper state?) and then when an edit is
sent across a link, it should be marked as "do not forward". This could be a part of the WALEdit
key or we could add support for tags to WALEdit (similar to cells) and add it there.

Thoughts?


was (Author: ishanc):
I agree. 

Let me setup a graph of HBase clusters for further discussion. Lets say we have 6 clusters,
C1..C6.
C1..C3 want to replicate to each other in the NxN fashion (i.e. with no forwarding) and the
following master master replications are setup: C4 <-> C3, C5 <-> C3 and C6 <->
C5

C4 <-> C3 <-> C5 <-> C6
           /    \
        C1 - C2

1. The source cluster sets the replication scope for the column family that is being replicated
as SINGLE_HOP_ONLY and the targets clusters do not forward KeyValues with families that have
their scope set as this. The decision on whether a write should be forwarded ahead thus lies
with the source cluster in this case. This will work if we just had C1..C3 but will *not*
work in the above example since a write from C4 will not have the correct scope set and will
circulate more in C1..C3 than needed. We could say that such a mixed setting is not supported,
but it is hard to prevent someone from shooting themselves in their foot.

2.  Having thought about this, this looks more like a property of the link (whether it is
a part of mesh network or a standard Master-Slave / Master-Master link). If a link is a part
of the mesh network, then *all* writes coming from that link (including ones that could have
originated at a different cluster) should not be forwarded. To do this setup, we would have
to add this as a property for the peer (in the zookeeper state?) and then when an edit is
sent across a link, it should be marked as "do not forward". This could be a part of the WALEdit
key or we could add support for tags to WALEdit (similar to cells) and add it there.

Thoughts?

> Mesh replication (a.k.a. multi master replication)
> --------------------------------------------------
>
>                 Key: HBASE-9934
>                 URL: https://issues.apache.org/jira/browse/HBASE-9934
>             Project: HBase
>          Issue Type: New Feature
>          Components: Replication
>            Reporter: Ishan Chhabra
>            Priority: Minor
>
> This is to setup NxN replication.
> See background discussion here: 
> http://mail-archives.apache.org/mod_mbox/hbase-user/201311.mbox/%3CCAOiuM-4UMmLA7UHMp4hhjpLWUrHDxg1t4tN4aWvnZUMcTxG%2BKQ%40mail.gmail.com%3E
> We can add a new mode in replication to not forward edits from other clusters. Not sure
what should be done when some clusters are configured with this setting and some aren't.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message