[
https://issues.apache.org/jira/browse/HBASE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048364#comment-13048364
]
Andrew Purtell commented on HBASE-2357:
---------------------------------------
bq. Another way to implement this functionality is for the slave(s) to loop on
the HLog.Reader?
Yes.
bq. Are there any potential problems with that?
Like with my above "first cut" proposal to scan HLogs upon roll, it would miss
anything not .writeToWAL(true).
bq. I'm not sure how the Coprocessor implementation would look, would the
master push entries out?
Yes, it would either stream updates out of all hooks for mutations or run a
consensus protocol in parallel with WAL commit out of the same.
bq. Isn't that somewhat problematic, eg, when a slave goes down, an entry isn't
sent or is skipped?
With simple streaming, when a slave goes down its replica becomes invalid and
should be simply discarded. So then I suppose there will be a period of time
after that happens, when a new slave is allocated and is behind until the
master sends over all the memstore. With ZAB, a transaction log and updates
from peers is part of the protocol.
> 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
