Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of zjusch@163.com designates
 220.181.13.27 as permitted sender)
Date: Sat, 16 Mar 2013 21:13:17 +0800 (CST)
From: "Chunhui Shen" <zjusch@163.com>
To: dev@hbase.apache.org
Subject: Re:Re: review request: HBASE-7403 Online Merge
In-Reply-To: 
 <CAPQV63UztdreS5fTgLf7nZXS4zgpfaB1qYVcaRt+HdndJq9R7g@mail.gmail.com>
References: 
 <CALte62zaG678GjOP_FJ_EYy4rOMeNQKgcTK3v7PxQ+aGPgpjuw@mail.gmail.com>
 <CAPQV63UztdreS5fTgLf7nZXS4zgpfaB1qYVcaRt+HdndJq9R7g@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="----=_Part_314028_1686845632.1363439597123"
MIME-Version: 1.0
Message-ID: <2fa59ae7.149fa.13d73553643.Coremail.zjusch@163.com>

------=_Part_314028_1686845632.1363439597123
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hey,JM,
 
When regions exist hole or overlap, administrator could merge non adjacent regions to keep table consistency,
otherwise we shouldn't merge non adjacent regions. I would point this out in the annotation

Thanks for the review

 
Chunhui


At 2013-03-16 20:52:48,"Jean-Marc Spaggiari" <jean-marc@spaggiari.org> wrote:
>Hi Ted,
>
>I jut gave it a look.
>
>I have updated it on the RB.
>
>Overall, this is very good and I'm eager to see that integrated! I'm
>waiting for this feature since the beginning ;)
>
>Regarding non adjacent regions merge? Will the system still be
>consistent after that? Or will hbck report some regions overlaps?
>
>JM
>
>
>2013/3/16 Ted Yu <yuzhihong@gmail.com>:
>> Hi,
>> On behalf of Chunhui, I am requesting review for HBASE-7403 Online Merge.
>>
>> This JIRA was created 3 months ago.
>> Chunhui has responded to review comments very promptly, including a major
>> rewrite around the time split transaction was rewritten.
>>
>> This feature has widely been requested. I feel the patch is mostly ready to
>> go in.
>> Here is brief recap of the steps.
>>
>> Process of merging two regions:
>>
>> a.client sends RPC (dispatch merging regions) to master
>> b.master moves the regions together (on the regionserver where the more
>> heavily loaded region resided)
>> c.master sends RPC (merge regions) to this regionserver
>> d.Regionserver executes the region merge transaction in the thread pool
>>
>> I think step b is a nice simplification for the problem. In previous
>> versions of the patch, the two merging regions stay on respective servers
>> which required more complex coordination through zookeeper.
>>
>> High level comment as well as detailed review are both welcome.
>>
>> Thanks

------=_Part_314028_1686845632.1363439597123--