hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel de Ferran <manuel.defer...@gmail.com>
Subject Re: Two regions with same start_key
Date Tue, 02 Mar 2010 08:17:51 GMT
Thanks !

I was a bit worried merging regions which do not follow strictly the B
-> C ; C -> D pattern.

On Mon, Mar 1, 2010 at 8:58 PM, Ryan Rawson <ryanobjc@gmail.com> wrote:
> I ran into these kinds of issues testing a pre-alpha hbase back in
> "the day"... If you have multiple regions that are weirdly
> overlapping, maybe as such:
>
> A -> B
> B -> C
> B -> D
> C -> F
> F -> G
> G -> H
>
> Here we see there are 3 "weird" regions, the [B,C) [B,D) and [C,F)
> regions... taken together they seem to form a reasonable continuous
> collection of keys, with the regions before and after them perfectly
> lining up.  The solution in this case is to do 2 merges: [B,C) & [B,D)
> -> [B,D) & [C,F)
>
> You can merge a lot of regions, my record is about 10 or so.  The
> normal system will split if necessary after booting up hbase again.
>
> One last tip, before you take hbase down, note the region names, since
> it might be hard to do so when hbase is down.
>
> -ryan
>
> On Sat, Feb 27, 2010 at 5:04 AM, Stack <stack@duboce.net> wrote:
>> Is it a failed split?  Its not an offlined parent with split
>> daughters?  It doesn't seem so.  I'd grep logs to see if I could
>> figure history of the regions but seems like you did that already.
>> You could merge the regions without data loss.  You need to first take
>> the table offline and then run the merge tool.
>>
>> hbase> disable "TABLENAME"
>>
>> Then once its offline:
>>
>> ./bin/hbase org.apache.hadoop.hbase.util.Merge
>>
>> That should printout usage.
>>
>> Good luck,
>> St.Ack
>>
>> On 2/25/10, Manuel de Ferran <manuel.deferran@gmail.com> wrote:
>>> Greetings,
>>>
>>> While browning a table, I noticed a strange thing in a couple of
>>> regions. I have two regions with same start_key, and two others with
>>> same end_key.
>>>
>>> Here are an extract of my regions list (s stands for 'start_key', and
>>> e for 'end_key') :
>>>
>>> R0 s : 1263184838004\x2F354030030657380\x2F3873287876323769 e:
>>> 1263192001699\x2Fa1000007c7afc6\x2F3880449775843972
>>>
>>> R1 s : 1263192001699\x2Fa1000007c7afc6\x2F3880449775843972 e :
>>> 1263204796594\x2F354030030723539\x2F3893245091353305
>>>
>>> R2 s : 1263192001699\x2Fa1000007c7afc6\x2F3880449775843972 e :
>>> 1263224608625\x2F358279017620731\x2F3913046476173954
>>>
>>> R3 s : 1263204796594\x2F354030030723539\x2F3893245091353305 e:
>>> 1263224608625\x2F358279017620731\x2F3913046476173954
>>>
>>> R4 s : 1263224608625\x2F358279017620731\x2F3913046476173954 e:
>>> 1263236230681\x2F351680031004439\x2F3924673427948082
>>>
>>> R5 s : 1263236230681\x2F351680031004439\x2F3924673427948082 e :
>>> 1263246691649\x2F358279018935781\x2F3935132932584112
>>>
>>>
>>> I expect contiguous regions. But I have smth like this :
>>> R0 -> R1 and R2
>>> R1 -> R3
>>> R2 -> R4
>>> R3 -> R4
>>> R4 -> R5
>>>
>>> instead of R0 -> R1 -> R2 ...
>>>
>>> I could not find anything in logfiles that could explain this "failed
>>> split". I was wondering how bad is this situation ? and how I could
>>> fix it ?
>>>
>>>
>>> Thanks
>>>
>>
>

Mime
View raw message