[
https://issues.apache.org/jira/browse/HBASE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048640#comment-13048640
]
Jason Rutherglen commented on HBASE-2357:
-----------------------------------------
{quote}A solution is for the master to stream edits to slaves from Put, Delete,
etc. post hooks via synchronous replication (or ZAB transaction). Could also be
via asynchronously drained replication queues that don't block the current
client operation unless full, but one should worry about increasing heap
pressure{quote}
Maybe we should call this 'push' based Coprocessor replication. A queue would
probably be necessary, as if a slave server goes down, we'd want to mitigate
the errant network calls. Would the push be multi-threaded?
I think the MySQL approach is the slave(s) connect to the master, then read the
transaction log starting from a given sequence id. The Coprocessor doesn't
enable that?
> 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
