Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of mohitanchlia@gmail.com
 designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <loom.20121224T172003-103@post.gmane.org>
References: 
 <CAE24rAdD9=c58XkS=gsaKJADQxfdyQRiiSONaYtu+yaMNm8c6g@mail.gmail.com>
	<8D483A32-1CD0-4C9E-AAC9-F4FE215735B4@mendeley.com>
	<CAE24rAeadQHQHQnNTPxr5T4cuR4kPSX0M5y6yv_8wztsiJLJVg@mail.gmail.com>
	<50475173.1000901@capptain.com>
	<loom.20121224T172003-103@post.gmane.org>
Date: Mon, 24 Dec 2012 09:53:47 -0800
Message-ID: 
 <CAOT3TWpP4CNC2Z=p78PeQi2jFhYuUCCu6BiwQZTU61GjdNLeRg@mail.gmail.com>
Subject: Re: Fixing badly distributed table manually.
From: Mohit Anchlia <mohitanchlia@gmail.com>
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=14dae9340d0f0fef6504d19ce1c3

--14dae9340d0f0fef6504d19ce1c3
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 24, 2012 at 8:27 AM, Ivan Balashov <ibalashov@gmail.com> wrote:

>
> Vincent Barat <vbarat@...> writes:
>
> >
> > Hi,
> >
> > Balancing regions between RS is correctly handled by HBase : I mean
> > that your RSs always manage the same number of regions (the balancer
> > takes care of it).
> >
> > Unfortunately, balancing all the regions of one particular table
> > between the RS of your cluster is not always easy, since HBase (as
> > for 0.90.3) when it comes to splitting a region, create the new one
> > always on the same RS. This means that if you start with a 1 region
> > only table, and then you insert lots of data into it, new regions
> > will always be created to the same RS (if you insert is a M/R job,
> > you saturate this RS). Eventually, the balancer at a time will
> > decide to balance one of these regions to other RS, limiting the
> > issue, but it is not controllable.
> >
> > Here at Capptain, we solved this problem by developing a special
> > Python script, based on the HBase shell, allowing to entirely
> > balance all the regions of all tables to all RS. It ensure that
> > regions of tables are uniformly deployed on all RS of the cluster,
> > with a minimum region transitions.
> >
>

Is it possible to describe the logic at high level on what you did?

> > It is fast, and even if it can trigger a lot of region transitions,
> > there is very few impact at runtime and it can be run safely.
> >
> > If you are interested, just let me know, I can share it.
> >
> > Regards,
> >
>
> Vincent,
>
> I would much like to see and possibly use the script that you
> mentioned. We've just run  into the same issue (after the table
> has been truncated it was re-created with only 1 region, and
> after data loading and manual splits we ended up having all
> regions within the same RS).
>
> If you could share the script, it will be really appreciated,
> I believe not only by me.
>
> Thanks,
> Ivan
>
>
>
>
>
>
>

--14dae9340d0f0fef6504d19ce1c3--