[
https://issues.apache.org/jira/browse/HBASE-18748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160331#comment-16160331
]
Anastasia Braginsky commented on HBASE-18748:
---------------------------------------------
Here is the summary of the design points for now:
1. A cache block load will earn a new type of WAL entry - cache-in WAL entry -
to be interleaved among other write-caused WAL entries.
2. No coprocessor observer is defined on cache-in event, so no coprocessor code
is going to be used. The suggestion is to modify the HBase internal code.
3. There is an idea to condition cache-in WAL entry creation to (1)
accumulation of X cache-in events or to (2) passing Y units of time. The early
among (1) and (2). Meaning the WAL update with cache-in WAL entry should be a
rare case.
Thus WAL size change (on top of the write WAL updates) should be really
minimal, hopefully not recognizable, subject to the benchmarking, of course.
4. When cache-in WAL entry appears on the other/secondary cluster side, it'd do
a read on the remote cluster which hopefully loads block to cache. Possible
feature extension is to make only cache-in event.
> 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)
