Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> Re: Extracting Zab from Zookeeper


Copy link to this message
-
Re: Extracting Zab from Zookeeper
> From: Mahadev Konar <[EMAIL PROTECTED]>
>
> 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?

Two ideas actually:

1) Do pretty straightforward log shipping from region master to read only replicas.

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.

#1 is relatively simple but trades away the consistency for which HBase is indicated for higher availability (for reads) when regions are in transition.

#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.

Both #1 and #2 would be offered as options to the system implementer.

Best regards,

    - Andy

Problems worthy of attack prove their worth by hitting back.
  - Piet Hein (via Tom White)
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB