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 8749118CD7 for ; Wed, 6 Jan 2016 18:23:20 +0000 (UTC) Received: (qmail 16100 invoked by uid 500); 6 Jan 2016 18:23:20 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 16023 invoked by uid 500); 6 Jan 2016 18:23:19 -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 16009 invoked by uid 99); 6 Jan 2016 18:23:19 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jan 2016 18:23:19 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 33896C065C for ; Wed, 6 Jan 2016 18:23:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.879 X-Spam-Level: ** X-Spam-Status: No, score=2.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id wdvGytlIcdTR for ; Wed, 6 Jan 2016 18:23:18 +0000 (UTC) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 36ED0231BC for ; Wed, 6 Jan 2016 18:23:18 +0000 (UTC) Received: by mail-qk0-f182.google.com with SMTP id h11so14856299qke.1 for ; Wed, 06 Jan 2016 10:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9LhqhrKBCQ5cEOAyCaLox5KSuQlHkJsDN/Gh/BzRCqI=; b=ZLApc3nmghMnN5M2nqLH8psBvNL2xb/E9CB8M5FFuvqn68YXMAfLxKdd8Ds/blIc9E w2oTaRJKETYrRRxzv6gei4QHU4rx/VzvqYOUevhA/uRCiaKUwNLjdeP5ZbZM133EnT8f yioYJhBu/KrnBlwvHkDwC9IlDDIIosSXWZSuZMUDyr+QVOaXdMFZHy2JwQ58AvKAp2IS iRP53n/Abs+X9bxJFdF9+ufBnaEIKe9wfkl8EVXY8KW+7f4CQPqd1JmNnI3+bS39eshV FIhnrLnJpFVqX1ZtooWJqdA7NQqHuoeNCmayVBWAdlCWadv5bVVY2ntY6pCKMBGdp5eE TtoQ== MIME-Version: 1.0 X-Received: by 10.129.29.14 with SMTP id d14mr66723389ywd.182.1452104591070; Wed, 06 Jan 2016 10:23:11 -0800 (PST) Received: by 10.37.207.5 with HTTP; Wed, 6 Jan 2016 10:23:11 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Jan 2016 10:23:11 -0800 Message-ID: Subject: Re: identifying source of region split request From: Ted Yu To: "dev@hbase.apache.org" Content-Type: multipart/alternative; boundary=001a114299aa53dfa70528ae72eb --001a114299aa53dfa70528ae72eb Content-Type: text/plain; charset=UTF-8 bq. collect statistics to blacklist some RSs with high failure rate The metadata would help pinpoint the regions which consistently fail split (merge) in the recent past. The failure could be due to corrupt HFile(s) or other reason. Having the statistics would also help normalizer avoid the following scenario: region R gets split into R1 and R2 size of R1 and R2 decreases due to expiration of data R1 and R2 get merged into R' more data comes into R', resulting in split, again Cheers On Wed, Jan 6, 2016 at 10:14 AM, Mikhail Antonov wrote: > Adding this tracing information to know who initiated split is in general > useful thing. Right now though I'm not sure I see how that would help to > make better normalization decisions? Region split failure implies > underlying FS issue? Any examples/ideas? > > Kind of..collect statistics to blacklist some RSs with high failure rate > and don't attempt to split regions hosted there in future? > > On Tue, Jan 5, 2016 at 2:55 PM, Ted Yu wrote: > > > Hi, > > I recently worked on improving region normalization feature. > > > > If region split request triggered by the execution of > > SplitNormalizationPlan fails, there is no way of knowing whether the > failed > > split originated from region normalization. > > Such association would give RegionNormalizer information so that it can > > make better normalization decisions in the subsequent invocations. > > > > One enhancement I can think of is to embed metadata in SplitRequest which > > gets passed through RegionStateTransitionContext when > > RegionServerServices#reportRegionStateTransition() is called. > > This way, RegionStateListener can be notified with the metadata (id of > the > > requester). > > > > Comment is welcome. > > > > > > -- > Thanks, > Michael Antonov > --001a114299aa53dfa70528ae72eb--