Hudson commented on HBASE-18477:

Results for branch HBASE-18477
        [build #292 on 
(x) *{color:red}-1 overall{color}*
details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 

(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 

(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 

(/) {color:green}+1 source release artifact{color}
-- See build output for details.

(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for 
 (note that this means we didn't run on Hadoop 3)

> Umbrella JIRA for HBase Read Replica clusters
> ---------------------------------------------
>                 Key: HBASE-18477
>                 URL: https://issues.apache.org/jira/browse/HBASE-18477
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Zach York
>            Assignee: Zach York
>            Priority: Major
>         Attachments: HBase Read-Replica Clusters Scope doc.docx, HBase 
> Read-Replica Clusters Scope doc.pdf, HBase Read-Replica Clusters Scope 
> doc_v2.docx, HBase Read-Replica Clusters Scope doc_v2.pdf
> Recently, changes (such as HBASE-17437) have unblocked HBase to run with a 
> root directory external to the cluster (such as in Amazon S3). This means 
> that the data is stored outside of the cluster and can be accessible after 
> the cluster has been terminated. One use case that is often asked about is 
> pointing multiple clusters to one root directory (sharing the data) to have 
> read resiliency in the case of a cluster failure.
> This JIRA is an umbrella JIRA to contain all the tasks necessary to create a 
> read-replica HBase cluster that is pointed at the same root directory.
> This requires making the Read-Replica cluster Read-Only (no metadata 
> operation or data operations).
> Separating the hbase:meta table for each cluster (Otherwise HBase gets 
> confused with multiple clusters trying to update the meta table with their ip 
> addresses)
> Adding refresh functionality for the meta table to ensure new metadata is 
> picked up on the read replica cluster.
> Adding refresh functionality for HFiles for a given table to ensure new data 
> is picked up on the read replica cluster.
> This can be used with any existing cluster that is backed by an external 
> filesystem.
> Please note that this feature is still quite manual (with the potential for 
> automation later).
> More information on this particular feature can be found here: 
> https://aws.amazon.com/blogs/big-data/setting-up-read-replica-clusters-with-hbase-on-amazon-s3/

This message was sent by Atlassian JIRA

Reply via email to