hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-2357) Coprocessors: Add read-only region replicas (slaves) for availability and fast region recovery
Date Mon, 13 Jun 2011 07:05:51 GMT

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

Andrew Purtell commented on HBASE-2357:

I do have mixed feelings. Slaves would need to access foreign store files for regions that
are not open on the RS. So then tailing HLogs, more foreign files, at the slave is not unreasonable.
But that is a major violation of assumptions that store files are private. Sharing store files
will require a coordination dance between master and slaves upon compaction and flushes. Sharing
active HLogs is more evil given the master may become involved. 

Also, the trouble with watching the WAL either on the slave side at the file or on the master
side with WALObserver is that .writeToWAL(false) edits will be unnoticed until flush. I'd
like to reevaluation if this limitation could be acceptable. Your thoughts? 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.

> Coprocessors: Add read-only region replicas (slaves) for availability and fast region
> ----------------------------------------------------------------------------------------------
>                 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


View raw message