[
https://issues.apache.org/jira/browse/HBASE-29081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986151#comment-17986151
]
Andor Molnar commented on HBASE-29081:
--------------------------------------
[~Li0829] Unfortunately we've found the previous ticket too late, we should
have been able to reuse code from that project. It's far from almost finish
though, the *refresh_meta* and *refresh_hfiles* commands which are the 2 major
components of the project are significantly or completely missing. Another
important difference is that the previous project was based on HBase 1.x branch
while in the new one we work on 2.x from the beginning.
> Add HBase Read Replica Cluster feature
> --------------------------------------
>
> Key: HBASE-29081
> URL: https://issues.apache.org/jira/browse/HBASE-29081
> Project: HBase
> Issue Type: Umbrella
> Components: Replication
> Reporter: Andor Molnar
> Assignee: Andor Molnar
> Priority: Major
>
> h1. Objective
> We’d like to implement the open source version of Amazon’s [Read Replica
> Cluster on
> S3|https://aws.amazon.com/blogs/big-data/setting-up-read-replica-clusters-with-hbase-on-amazon-s3/]
> feature for Apache HBase. It adds the ability of running another HBase
> cluster on the same cloud storage location in read-only mode, allowing users
> to share the read workload between multiple clusters. Due to the
> characteristics of the implementation and the lack of automated
> synchronization between the active and read-replica clusters, read replicas
> are eventually consistent, hence they’re not suitable for reading most recent
> data. However we still believe that users of open source Apache HBase could
> take advantage of this feature and there’re use cases out there which read
> replicas could help with. Please find more information about the feature in
> the linked blog post.
> h1. Pros
> * Running multiple clusters in different Availability Zones adds HA to the
> entire workload,
> * No need for data movement or duplication (active-active replication setup)
> which is cost and time efficient,
> * No limit for the number of read replica clusters
> h1. Cons
> * Read Replica clusters are eventually consistent: in memory data is not
> visible from read replicas,
> * Read Replica clusters must be manually refreshed: flush on active cluster,
> refresh hfiles/meta on read replicas
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
