hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Daniel Cryans <jdcry...@apache.org>
Subject Re: Wondering what hbck should do in this situation
Date Thu, 19 Jul 2012 18:05:12 GMT
Thanks for the jira Jimmy, it seems to me that we should aim for a dry
run feature first and then consider the interactive part. At least it
would give the user an opportunity to fix problems that would
otherwise make things worse.


On Thu, Jul 19, 2012 at 11:02 AM, Jimmy Xiang <jxiang@cloudera.com> wrote:
> HBASE-5324 is the one I filed on interactive hbck.  We can use it if
> there is no duplicate one.
> Thanks,
> Jmmy
> On Thu, Jul 19, 2012 at 10:55 AM, Jonathan Hsieh <jon@cloudera.com> wrote:
>> Jimmy and I have been adding features essentially as we've needed them,
>> including some options that limit fixes to particular tables, and limit the
>> kinds of fixes that are applied.
>> There is a jira for making the repairs interactive -- either a hbck shell,
>> an interactive mode that provides a series of y/n questions.  I'd be
>> amenable to any of these kinds of improvements.
>> Jon.
>> On Thu, Jul 19, 2012 at 10:50 AM, Jean-Daniel Cryans <jdcryans@apache.org>wrote:
>>> On Wed, Jul 18, 2012 at 9:56 PM, Ramkrishna.S.Vasudevan
>>> <ramkrishna.vasudevan@huawei.com> wrote:
>>> > J-d
>>> > Corrections, if META does not have an entry then we cannot know if it is
>>> > splitted or not.. Apologies for that.
>>> >
>>> > I think we need to check for Reference files and if the opening fails we
>>> > need to report it.  That should be the way.
>>> > But we should also confirm whether this region was split properly, right?
>>> That's what I'm wondering about. It seems to me that hbck currently is
>>> overly aggressive fixing things (see also HBASE-6417 where it merged
>>> .META.). So should we have all the heuristics to detect problems and
>>> then add the corner cases after as people find them? Or should we let
>>> the users decide what should be fixed? It could be that we should ask
>>> more questions to the users. I'm thinking out loud here.
>>> J-D
>> --
>> // Jonathan Hsieh (shay)
>> // Software Engineer, Cloudera
>> // jon@cloudera.com

View raw message