Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 10 Sep 2017 12:51:01 +0000 (UTC)
From: "Anastasia Braginsky (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13099450.1504442153000.71402.1505047861349@Atlassian.JIRA>
In-Reply-To: <JIRA.13099450.1504442153000@Atlassian.JIRA>
References: <JIRA.13099450.1504442153000@Atlassian.JIRA> <JIRA.13099450.1504442153377@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-18748) Cache pre-warming upon replication
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 10 Sep 2017 12:51:11 -0000


    [ 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)