Mailing-List: contact hbase-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-user@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of manuel.deferran@gmail.com
 designates 209.85.220.213 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=xdiYTxFUWUioM77XAiW0Jpwn6ObrXaX3CnTV5RH+PSFHmzVaJaufg4d0Et5U0ZYTpD
         OezZMlQn8l3xwN9UsiIduhMUWrnpxcykfVQS9ewuSLQ3oMjijFmKD1NuPBYR4pyTeyDu
         ZFdwAt9VCw2/a4ka0WiYUT39Fmz7oPXiY4Y4A=
MIME-Version: 1.0
In-Reply-To: <78568af11003011158m2661ef82y408408adc8389f18@mail.gmail.com>
References: <1f6afe4a1002250902x29ab4c4bx54f7e72a09af1b3b@mail.gmail.com>
	 <7c962aed1002270504g36cc9af7y6d7542a638618125@mail.gmail.com>
	 <78568af11003011158m2661ef82y408408adc8389f18@mail.gmail.com>
Date: Tue, 2 Mar 2010 09:17:51 +0100
Message-ID: <1f6afe4a1003020017x42af6b9cte296b9d2692dc15b@mail.gmail.com>
Subject: Re: Two regions with same start_key
From: Manuel de Ferran <manuel.deferran@gmail.com>
To: hbase-user@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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. =A0The 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. =A0The
> 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? =A0Its not an offlined parent with split
>> daughters? =A0It doesn't seem so. =A0I'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. =A0You 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
>>>
>>
>