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.

J-D

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

Mime
View raw message