[
https://issues.apache.org/jira/browse/HBASE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030892#comment-13030892
]
Jason Rutherglen commented on HBASE-2357:
-----------------------------------------
@Andrew The ZAB would be very cool, as then there wouldn't be a need for too
much logic when a master fails? However I wonder about the write performance,
as it means additional network overhead (to each node) per write?
bq. Initial thoughts on this is a region slave can get notice from the region
owner via zk that a log has rolled and process the new edits from there
What is the expected latency between a write and then reading the new value(s)
from the slave? I'm not sure if this means writing a series of WAL edits to a
file, then waiting for the file to reach a given limit (?), and then the slave
reads from the newly flushed log in HDFS? If this is the case, perhaps we'll
want to implement replication that is more immediate (like MySQL)?
> Coprocessors: Add read-only region replicas (slaves) for availability and
> fast region recovery
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-2357
> URL: https://issues.apache.org/jira/browse/HBASE-2357
> Project: HBase
> Issue Type: Sub-task
> Components: master, regionserver
> Reporter: Todd Lipcon
> Assignee: Andrew Purtell
>
> I dont plan on working on this in the short term, but the idea is to extend
> region ownership to have two modes. Each region has one primary region server
> and N slave region servers. The slaves would follow the master (probably by
> streaming the relevant HLog entries directly from it) and be able to serve
> stale reads. The benefit is twofold: (a) provides the ability to spread read
> load, (b) enables very fast region failover/rebalance since the memstore is
> already nearly up to date on the slave RS.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
