You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Varun Sharma (JIRA)" <ji...@apache.org> on 2013/07/10 19:29:49 UTC

[jira] [Commented] (HBASE-8434) Allow enabling hbase 8354 to support real lease recovery

    [ https://issues.apache.org/jira/browse/HBASE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13704786#comment-13704786 ] 

Varun Sharma commented on HBASE-8434:
-------------------------------------

So with 0.94 there are two cases:

1) Without mandatory lease recovery
In this case, the above config could add upto 60s + 60s or 2 minutes to MTTR. This is because the first lease recovery will never truly happen without HDFS 4721 - the reason being that the dead datanode will be chosen as primary data node but then that data node is no longer heart beating - so the lease recovery will never truly commence. That adds 60 seconds, then another 60 second wait after the second invocation.

For folks, who don't really care about lease recovery (minor data loss), I am not sure if changing the config is the write thign to do.

2) With mandatory lease recovery
Again we add 120 seconds to MTTR, but then, we will end up enforcing real lease recovery even with the default hdfs timeouts.
                
> Allow enabling hbase 8354 to support real lease recovery
> --------------------------------------------------------
>
>                 Key: HBASE-8434
>                 URL: https://issues.apache.org/jira/browse/HBASE-8434
>             Project: HBase
>          Issue Type: Improvement
>          Components: MTTR
>            Reporter: Varun Sharma
>            Assignee: Varun Sharma
>             Fix For: 0.94.10
>
>         Attachments: 8434.patch
>
>
> Please see discussion in HBase 8389.
> For environments where lease recovery time can be bounded on the HDFS side through tight timeouts, provide a toggle for users who want the WAL splitting to continue only after the lease is truly recovered and the file is closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira