Hi Flavio, > I don't understand why you have to ship the log to the read only replicas. > Aren't you storing the log on HDFS currently? Can't they read from HDFS > directly?
Possibly the replicas can "tail" the WAL of the master, was using the term log shipping in the abstract. However I'm not an HDFS expert so unsure if we could read the last (partial) block in the WAL. Newly written data exists only in memory so the WAL would be the only option for transmitting this data until flush without some sort of direct replication. > I wonder why you are choosing 3 for the size of a clique and not letting it > be a free parameter. It would but 3 seems a reasonable default. (?) > Are you choosing 3 to avoid the replication overhead? Yes. > #1 is relatively simple but trades away the consistency > I don't see where you could have inconsistencies here. Would you mind > elaborating a bit further? At any given instant queries to a replica may not return the same result as the (write) master for data in memstore and (possibly) in the last block of the WAL. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) --- On Wed, 2/2/11, Flavio Junqueira <f...@yahoo-inc.com> wrote: From: Flavio Junqueira <f...@yahoo-inc.com> Subject: Re: Extracting Zab from Zookeeper Date: Wednesday, February 2, 2011, 2:14 AM Hi Andrew, Interesting use case, thanks for sharing. I'm curious about a few things: On Feb 1, 2011, at 5:38 PM, Andrew Purtell wrote: Two ideas actually: 1) Do pretty straightforward log shipping from region master to read only replicas. I don't understand why you have to ship the log to the read only replicas. Aren't you storing the log on HDFS currently? Can't they read from HDFS directly? 2) Divide the cluster into quorum 3-cliques. Extract ZAB and use it to maintain consensus on writes from region master to two read only replicas. Run the consensus protocol in parallel with HDFS hflush to the write ahead log. Needs a lot of work filling in the detail, obviously, but that's the general notion. I wonder why you are choosing 3 for the size of a clique and not letting it be a free parameter. I would think that this a decision of the user. Are you choosing 3 to avoid the replication overhead? #1 is relatively simple but trades away the consistency for which HBase is indicated for higher availability (for reads) when regions are in transition. I don't see where you could have inconsistencies here. Would you mind elaborating a bit further? #2 is not simple at all but may let maintain replicas that are fully consistent at all times with the region master, not lower region master write performance unacceptably, and also gain the higher availability (for reads) when regions are in transition. Agreed, it will be tricky, especially because we would have to extract Zab first. Cheers,-Flavio flavio junqueira research scientist f...@yahoo-inc.com direct +34 93-183-8828 avinguda diagonal 177, 8th floor, barcelona, 08018, es phone (408) 349 3300 fax (408) 349 3301