Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7E42DD541 for ; Sat, 16 Mar 2013 13:51:59 +0000 (UTC) Received: (qmail 67036 invoked by uid 500); 16 Mar 2013 13:51:58 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 66797 invoked by uid 500); 16 Mar 2013 13:51:58 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 66771 invoked by uid 99); 16 Mar 2013 13:51:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Mar 2013 13:51:57 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.160.53] (HELO mail-pb0-f53.google.com) (209.85.160.53) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Mar 2013 13:51:53 +0000 Received: by mail-pb0-f53.google.com with SMTP id un1so5014270pbc.12 for ; Sat, 16 Mar 2013 06:51:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=xT+CMH0LoT+LMOBXvrujUFXmygLntHa20Xrk234YMrk=; b=g3mUJ5VPjTfHY+1CRVR8VFHcXev7Ial8ajevxrCRqc5xXdr8SZe5RoF0AvBDlB6rVj yFU7xjgQI4pjINylltC7e3rUkmzHaGTrkX4IuofTRbKtqUh8xut9wWu6+qE/gexWmyiW qvBsGIiiniwL8W5/bMrTmVWR3+Njj6hy1qSidQmoxtEVpGvyb2kL4OKYkmn4cojuMR8A sywAX4toUPiWXcrMFVTBzPKZqRWUc8GiGKv8Mlmn8q1YDZ2cBHo4OPGWBGam5xDSWVqs vGRGlPwCuAvvSVMu310HLBKzH7Gftq9fmewsJOQBUsTh8/ItDa1mtB46mCSi3gpG1QOA Z9+w== X-Received: by 10.68.102.165 with SMTP id fp5mr23458658pbb.82.1363441892958; Sat, 16 Mar 2013 06:51:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.3.197 with HTTP; Sat, 16 Mar 2013 06:51:12 -0700 (PDT) In-Reply-To: References: <9DBACDDA-3654-45CC-ACB1-FE81226D20DF@gmail.com> From: Jean-Marc Spaggiari Date: Sat, 16 Mar 2013 09:51:12 -0400 Message-ID: Subject: Re: review request: HBASE-7403 Online Merge To: dev@hbase.apache.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnIMQx5pN3WQ+e+hKo2uXyNniW2dUQrPZhgmAQ7XHdzCeAI3Glfz6/59iOKkWowkRaj+vNJ X-Virus-Checked: Checked by ClamAV on apache.org I see. I agree that we should throw a warning at least, when someone is trying to merge such regions. Might still be good to have this possibility. JM 2013/3/16 Kevin O'dell : > 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" 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 >> 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 : >> >> 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 >>