[
https://issues.apache.org/jira/browse/HBASE-18748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154602#comment-16154602
]
Zach York commented on HBASE-18748:
-----------------------------------
[~anastas] Do you guys already enable this config? This can be used to limit
latency spikes, but it seems like you want it to already be prewarmed.
/**
* Configuration key to prefetch all blocks of a given file into the block
cache
* when the file is opened.
*/
public static final String PREFETCH_BLOCKS_ON_OPEN_KEY =
"hbase.rs.prefetchblocksonopen";
Also you are mentioning multiple clusters here, have you taken a look at
https://issues.apache.org/jira/browse/HBASE-18477? It might not be exactly what
you are looking for, but it could help.
> 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)
