[
https://issues.apache.org/jira/browse/HBASE-18748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160328#comment-16160328
]
Anastasia Braginsky commented on HBASE-18748:
---------------------------------------------
Hey, [~zyork]!
Sorry for late reply and thanks for your suggestions and references.
bq. Do you guys already enable this config?
No, it is yet to be implemented.
bq. Configuration key to prefetch all blocks of a given file into the block
cache when the file is opened.
This is not exactly what we are talking about. We want to load only some blocks
on secondary and only due to correlated cache load of the blocks on primary.
bq. Also you are mentioning multiple clusters here, have you taken a look at
https://issues.apache.org/jira/browse/HBASE-18477?
Thanks for the reference. Again, this is not exactly what we are talking about
but nice reference to look on.
> 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)
