Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> review request: HBASE-7403 Online Merge

Copy link to this message
Re: review request: HBASE-7403 Online Merge
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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>:
>>>> 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