hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted <yuzhih...@gmail.com>
Subject Re: review request: HBASE-7403 Online Merge
Date Sat, 16 Mar 2013 13:40:16 GMT
I have a few thoughts on your questions. 

But I think we should give Chunhui a chance to answer these questions first. 

Btw the improvement in handling region split by Enis is fairly new. Meaning hbck hasn't utilized
this new model yet. 


On Mar 16, 2013, at 6:21 AM, "Kevin O'dell" <kevin.odell@cloudera.com> wrote:

> Ted,
>  Why would we use that merge tool when hbck will repair that?  Should we
> throw a warning and tell the user to run repair first?
> On Mar 16, 2013 9:17 AM, "Ted" <yuzhihong@gmail.com> wrote:
>> Chunhui replied to this question on review board.
>> Basically the force option is to repair overlapping regions or table with
>> hole in its regions.
>> Personally I think online merge should detect merging regions with hole in
>> between them and not require force flag in that case because logically
>> they're adjacent.
>> Cheers
>> On Mar 16, 2013, at 5:52 AM, 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

View raw message