Return-Path: 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 DAD7510E79 for ; Fri, 8 Nov 2013 22:33:50 +0000 (UTC) Received: (qmail 82207 invoked by uid 500); 8 Nov 2013 22:33:48 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 82152 invoked by uid 500); 8 Nov 2013 22:33:48 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 82144 invoked by uid 99); 8 Nov 2013 22:33:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Nov 2013 22:33:48 +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 (nike.apache.org: domain of yuzhihong@gmail.com designates 209.85.215.41 as permitted sender) Received: from [209.85.215.41] (HELO mail-la0-f41.google.com) (209.85.215.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Nov 2013 22:33:42 +0000 Received: by mail-la0-f41.google.com with SMTP id ea20so2431208lab.0 for ; Fri, 08 Nov 2013 14:33:21 -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 :content-type; bh=9ijqyP+cY8dHUvujxBONW79wyS9LOHqFUqGyWnO5Buw=; b=Cx7p7wjsH5hwbCtEMKlSqq+DpMx2yvdwwnm7uM0YlG8d7o4J9NupyGJ5t5vnkSZyde qY0BkZaHMGpbgYe/rqvfReSpMYHPksfvIUxxuwMM1syfPxeuEjxE6Mz3bX9Tj//pCH01 1ZT0YnQ9GnAOa3X1Cdgu7E8qEDWfjJpaRSL/K+lKDVUudmVUifazYnOszQ7tFjZnI6+D EGWxP6g9vodXihQoCeh3Ykc4AFuK7rQ6lEtI/aojgSRzGeLrBCblSfckugZQz9gb/QW4 hGrV5zAorVltXz00wrgalC8btfX4mIxgbOwGu+0H8JeeUhxajC1qlxgCZ188E3PdvtA/ G86A== MIME-Version: 1.0 X-Received: by 10.112.125.7 with SMTP id mm7mr772246lbb.24.1383950001467; Fri, 08 Nov 2013 14:33:21 -0800 (PST) Received: by 10.112.129.40 with HTTP; Fri, 8 Nov 2013 14:33:21 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 14:33:21 -0800 Message-ID: Subject: Re: Setting up NxN replication From: Ted Yu To: "user@hbase.apache.org" Content-Type: multipart/alternative; boundary=089e0115e7b439762104eab1f8b6 X-Virus-Checked: Checked by ClamAV on apache.org --089e0115e7b439762104eab1f8b6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ishan: In your use case, the same table is written to in 10 clusters at roughly the same time ? Please clarify. On Fri, Nov 8, 2013 at 2:29 PM, Ishan Chhabra wrot= e: > @Demai, > We actually have 10 clusters in different locations. > The replication scope is not an issue for me since I have only one column > family and we want it replicated to each location. > Can you elaborate more on why a replication setup of more than 3-4 cluste= rs > would be a headache in your opinion? > > > On Fri, Nov 8, 2013 at 2:16 PM, Ishan Chhabra >wrote: > > > @Demai, > > Writes from B should also go to A and C. So, if I were to continue on > your > > suggestion, I would setup A-B master master and B-C master-master, whic= h > is > > what I was proposing in the 2nd approach (MST based). > > > > @Vladimir > > That is classified. :P > > > > > > On Fri, Nov 8, 2013 at 1:20 PM, Vladimir Rodionov < > vladrodionov@gmail.com>wrote: > > > >> *I want to setup NxN replication i.e. N clusters each replicating to > each > >> other. N is expected to be around 10.* > >> > >> Preparing to thermonuclear war? > >> > >> > >> > >> > >> On Fri, Nov 8, 2013 at 1:14 PM, Ishan Chhabra >> >wrote: > >> > >> > 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 fi= x, > >> but > >> > 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 > >> the > >> > direct path. This leads to unnecessary network usage and writes to W= AL > >> 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 > >> and > >> > WAL usage. It also suffers from a failure scenarios where the a sing= le > >> > 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. > >> > > >> > > > > > > > > -- > > *Ishan Chhabra *| Rocket Scientist | RocketFuel Inc. > > > > > > -- > *Ishan Chhabra *| Rocket Scientist | RocketFuel Inc. > --089e0115e7b439762104eab1f8b6--