Have now: HBASE-7158 :)
________________________________ From: Marcos Ortiz <[email protected]> To: lars hofhansl <[email protected]> Cc: [email protected]; Varun Sharma <[email protected]> Sent: Tuesday, November 13, 2012 3:29 PM Subject: Re: Master Master replication Regards, Lars, it would be nice to work on this. Have you filed a JIRA issue for it? On 11/13/2012 05:15 PM, Varun Sharma wrote: > I think we should - otherwise this makes replication setup rather difficult > for clusters which are already running in production. Since, between the > copy table import and the replication setup, you would end up losing some > writes. > > Varun > > On Tue, Nov 13, 2012 at 1:52 PM, lars hofhansl <[email protected]> wrote: > >> I wonder whether we should have an option in CopyTable that identifies the >> originating cluster and avoids that copying back. >> When I implemented master-master replication I only added that to the >> replication source (so that edit do not bounce between the masters forever). >> >> -- Lars >> >> >> >> ________________________________ >> From: Himanshu Vashishtha <[email protected]> >> To: [email protected] >> Sent: Tuesday, November 13, 2012 1:45 PM >> Subject: Re: Master Master replication >> >> On Tue, Nov 13, 2012 at 1:36 PM, Varun Sharma <[email protected]> wrote: >>> Hi, >>> >>> I want to setup a master-master replicated cluster using Hbase 0.94 - the >>> two clusters will be in different availability zones. I was wondering if >>> the following would work: >>> >>> 1) Setup cluster A and start reading/writing to it and run it for a week. >>> 2) Now Setup cluster B and configure the two clusters as Master-Master. >>> >>> Is it possible to have such a setup, basically adding a master replica to >>> an existing standalone hbase cluster ? >> It will behave as master-master from the time you set that up (from >> the current WALs). >> >> Once the setup happens, would B >>> inherit all of data that was written to cluster A prior to the >> replication >>> setup ? >> No, you need to run a copyTable job to do so. Note that you need to >> run the copyTable before starting the replication otherwise, B will >> send it back to A. >> a) Run the copyTable job, (note the start timestamp of the job). >> b) Start the replication. >> c) Run the copyTable again with starttime equal to the starttime >> noted in step 1. >> >> >>> Thanks >>> Varun > > 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS > INFORMATICAS... > CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION > > http://www.uci.cu > http://www.facebook.com/universidad.uci > http://www.flickr.com/photos/universidad_uci -- Marcos Luis Ortíz Valmaseda about.me/marcosortiz <http://about.me/marcosortiz> @marcosluis2186 <http://twitter.com/marcosluis2186> 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci
