[
https://issues.apache.org/jira/browse/HBASE-18748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152923#comment-16152923
]
stack commented on HBASE-18748:
-------------------------------
What you thinking [~anastas] ? The WAL hosts all writes to hbase. It does not
do reads. Our cache is pluggable. You could reference a cache that overloads
our default that does a write to WAL (async) whenever we pull in a block?
Something like that? I don't think we have any hooks other than what
implementation to load in cache implementation currently.
> Cache pre-warming upon replication
> ----------------------------------
>
> Key: HBASE-18748
> URL: https://issues.apache.org/jira/browse/HBASE-18748
> Project: HBase
> Issue Type: New Feature
> Reporter: Anastasia Braginsky
>
> HBase's cluster replication is very important and widely used feature. Let's
> assume primary cluster is replicated to secondary (backup) cluster using the
> WAL of the primary cluster to propagate the changes. Let's also assume the
> secondary cluster is a target for failover when needed and should become
> primary when needed.
> We suggest improving the way the HBase cluster failover works today. Namely,
> upon failover, the backup RS's cache is cold. Warming it up to the right
> working set takes many minutes. The suggested solution is to selectively
> replay read requests at the backup - namely, those reads that caused
> cache-ins at the primary. We intend to use WAL replication as transport
> protocol (hopefully, as black box), and of course add custom replay
> callbacks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
