Removing user@apache, Wow... That¹s pretty interesting. Unfortunately the apache site is down. But reading from the cached archives, it feels like the jira is about master-slave for read only replica of the region servers?
Thanks Mahadev On 1/30/11 4:56 PM, "Andrew Purtell" <[email protected]> wrote: > FWIW, we have this crazy idea of using something like an extracted ZAB for > maintaining quorum-cliques in a modified HBase cluster: > https://issues.apache.org/jira/browse/HBASE-2357 > > - Andy > >> From: Benjamin Reed <[email protected]> >> Subject: Re: Extracting Zab from Zookeeper >> To: "[email protected]" <[email protected]> >> Cc: "Ted Dunning" <[email protected]>, "[email protected]" >> <[email protected]> >> Date: Friday, January 28, 2011, 10:27 AM >> flavio and ted are correct. zab and >> zookeeper are tightly coupled, and >> as flavio points out, zab provides a bit more than just >> atomic broadcast. >> >> i think it would be a good thing to do for three reasons: >> >> 1) it would make testing, benchmarking, and fixing that layer >> (especially for ZOOKEEPER-22) much easier. >> 2) we could try different backends easier. (i'd love to try >> using bookkeeper for example.) >> 3) although the zab interface must be richer than normal >> atomic broadcast (access to past transactions, for example), i >> think in practice applications that do primary/backup can benefit >> from this richer interface. >> >> ben >> >> On 01/28/2011 07:03 AM, Ted Dunning wrote: >>> I think that what Flavio was saying is that it is like >>> pulling a string on a sweater. Almost any application that >>> wants ZAB is probably going to need the broadcast and they the >>> broadcast, they will want to have logging. And transactions. >>> And so on. >>> >>> Moreover, some of these features are not necessarily >>> encoded in ZK in a way that you can point to. Instead they are >>> enabled by the way that several functional units are glued >>> together. > > > > >
