Return-Path: 
 <user-return-39963-apmail-hbase-user-archive=hbase.apache.org@hbase.apache.org>
X-Original-To: apmail-hbase-user-archive@www.apache.org
Delivered-To: apmail-hbase-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 5903510C02
	for <apmail-hbase-user-archive@www.apache.org>;
 Fri,  8 Nov 2013 21:20:44 +0000 (UTC)
Received: (qmail 36807 invoked by uid 500); 8 Nov 2013 21:20:41 -0000
Delivered-To: apmail-hbase-user-archive@hbase.apache.org
Received: (qmail 36710 invoked by uid 500); 8 Nov 2013 21:20:40 -0000
Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@hbase.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@hbase.apache.org>
List-Post: <mailto:user@hbase.apache.org>
List-Id: <user.hbase.apache.org>
Reply-To: user@hbase.apache.org
Delivered-To: mailing list user@hbase.apache.org
Received: (qmail 36694 invoked by uid 99); 8 Nov 2013 21:20:40 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Nov 2013 21:20:40 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of nidmgg@gmail.com designates
 209.85.212.41 as permitted sender)
Received: from [209.85.212.41] (HELO mail-vb0-f41.google.com) (209.85.212.41)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Nov 2013 21:20:36 +0000
Received: by mail-vb0-f41.google.com with SMTP id w8so1821829vbj.0
        for <multiple recipients>; Fri, 08 Nov 2013 13:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=yv0BztB7g9NnL2aWfi13AzdhMAiQ5IG7F7+z065gyVc=;
        b=uKzrnY1kHHOb4RqDe7QLui+YjUZoo1vIGAMWf++p4ruX53I2JkjTlA/oJrOJBC9/2O
         rkfu+SVLQgVM/NifgKxRFdh83lR618HfGAfzY8YRGYXCFgR+G6hTsuwzrOtDiX6HyuG6
         LrhU99bKVRX64yDzpwHzREnoQv5I769485zXmZFXa4Hh0NOGmzuXhRB2gZ7JFl+vND9Y
         8/BNGeMFUFYVfULQCJTWpGp8qY//SD7KQbZo//9RTYu6Bym8ydF09DdNkFue39xyfvnC
         UWknIE5JykA1rc2YpczuwTqYf+E2ICPTHiMddlr3QlTK4IC2DiYfgiXB/1Y1R7h+rcPJ
         tFzA==
MIME-Version: 1.0
X-Received: by 10.58.217.130 with SMTP id oy2mr13755396vec.24.1383945615888;
 Fri, 08 Nov 2013 13:20:15 -0800 (PST)
Received: by 10.221.28.136 with HTTP; Fri, 8 Nov 2013 13:20:15 -0800 (PST)
In-Reply-To: 
 <CAOiuM-4UMmLA7UHMp4hhjpLWUrHDxg1t4tN4aWvnZUMcTxG+KQ@mail.gmail.com>
References: 
 <CAOiuM-4UMmLA7UHMp4hhjpLWUrHDxg1t4tN4aWvnZUMcTxG+KQ@mail.gmail.com>
Date: Fri, 8 Nov 2013 13:20:15 -0800
Message-ID: 
 <CAOEq2C7Njb1_HDAMBVtLp++fxSiXhLJPMv1xaLq2zrxh6bVfNQ@mail.gmail.com>
Subject: Re: Setting up NxN replication
From: Demai Ni <nidmgg@gmail.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7bdc051ed2d85604eab0f2e4
X-Virus-Checked: Checked by ClamAV on apache.org

--047d7bdc051ed2d85604eab0f2e4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

hi, Ishan,

can you please elaborate a bit about your use case?

for your example of 3 cluster, I think it should be set up as two M-S for
the same table:family
first one: A =3D Master, B =3D Slave
2nd one: B =3D slave, C =3D Master.
There is no need to setup the direct relationship between A and C

Demai


On Fri, Nov 8, 2013 at 1:14 PM, Ishan Chhabra <ichhabra@rocketfuel.com>wrot=
e:

> I want to setup NxN replication i.e. N clusters each replicating to each
> other. N is expected to be around 10.
>
> On doing some research, I realize it is possible after HBASE-7709 fix, bu=
t
> it would lead to much more data flowing in the system. eg.
>
> Lets say we have 3 clusters: A,B and C.
> A new write to A will go to B and then C, and also go to C directly via t=
he
> direct path. This leads to unnecessary network usage and writes to WAL of
> B, that should be avoided. Now imagine this with 10 clusters, it won=92t
> scale.
>
> One option is to create a minimum spanning tree joining all the clusters
> and make nodes replicate to their immediate peers in a master-master
> fashion. This is much better than NxN mesh, but still has extra network a=
nd
> WAL usage. It also suffers from a failure scenarios where the a single
> cluster going down will pause replication to clusters downstream.
>
> What I really want is that the ReplicationSource should only forward
> WALEdits with cluster-id same as the local cluster-id. This seems like a
> straight forward patch to put in.
>
> Any thoughts on the suggested approach or alternatives?
>
> --
> *Ishan Chhabra *| Rocket Scientist | RocketFuel Inc.
>

--047d7bdc051ed2d85604eab0f2e4--