hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12070) Add an option to hbck to fix ZK inconsistencies
Date Fri, 30 Jan 2015 20:32:34 GMT

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

Hadoop QA commented on HBASE-12070:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against branch-1 branch at commit b08802a3e8e522f84519415b83455870b49bf8da.
  ATTACHMENT ID: 12695345

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 6 new or modified

    {color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/12649//console

This message is automatically generated.

> Add an option to hbck to fix ZK inconsistencies
> -----------------------------------------------
>                 Key: HBASE-12070
>                 URL: https://issues.apache.org/jira/browse/HBASE-12070
>             Project: HBase
>          Issue Type: Bug
>          Components: hbck
>    Affects Versions: 1.1.0
>            Reporter: Sudarshan Kadambi
>            Assignee: Stephen Yuan Jiang
>             Fix For: 1.1.0
>         Attachments: HBASE-12070.v1-branch-1.patch
> If the HMaster bounces in the middle of table creation, we could be left in a state where
a znode exists for the table, but that hasn't percolated into META or to HDFS. We've run into
this a couple times on our clusters. Once the table is in this state, the only fix is to rm
the znode using the zookeeper-client. Doing this manually looks a bit error prone. Could an
option be added to hbck to catch and fix such inconsistencies?
> A more general issue I'd like comment on is whether it makes sense for HMaster to be
maintaining its own write-ahead log? The idea would be that on a bounce, the master would
discover it was in the middle of creating a table and either rollback or complete that operation?
An issue that we observed recently was that a table that was in DISABLING state before a bounce
was not in that state after. A write-ahead log to persist table state changes seems useful.
Now, all of this state could be in ZK instead of the WAL - it doesn't matter where it gets
persisted as long as it does.

This message was sent by Atlassian JIRA

View raw message