[ 
https://issues.apache.org/jira/browse/HBASE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048716#comment-13048716
 ] 

Jason Rutherglen commented on HBASE-2357:
-----------------------------------------

{quote}That is not how HBase RPC works. One connection between the endpoints 
(in this case regionserver and regionserver) is established upon demand, reaped 
when idle too long, and multiplexed over in the meantime.
{quote}

Ok, great.  The replication master will need to examine ZK, and find out which 
slaves to RPC connect to.  

{quote}And spill the queues under heap pressure presumably. Or give up on a too 
laggy slave and have it killed to avoid blowing out heap in the 
alternative{quote}

Spilling would probably add too much complexity (eg, where would it spill to?). 
 I think we need to define how a slave gets too far behind, and then assume 
it'll need to refresh itself when it does (on a per-region basis, or does the 
entire RS need to recover?).

bq. No we need to think of the HMaster as always on the verge of going away to 
be supplanted by ZooKeeper mediated distributed actions.

Ok, good to know.  Before implementing we should hammer this part of the design 
out.

> 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

        

Reply via email to