Is there ever a reason to not attempt retaining assignments?
----- Original Message ----- From: Ted Yu <yuzhih...@gmail.com> To: dev@hbase.apache.org Cc: Sent: Tuesday, July 23, 2013 8:58 AM Subject: Re: Smarter Region assignment policy? In trunk, we have the following code in HMaster#enableTable(): this.executorService.submit(new EnableTableHandler(this, tableName, catalogTracker, assignmentManager, tableLockManager, false ).prepare()); The boolean value of false means the assignment wouldn't retain region locations (compared to the locations prior to disabling). In 0.94, I see similar code. Looks like we can add new API where user can specify whether retainAssignment should be used. Cheers On Mon, Jul 22, 2013 at 4:21 PM, Vladimir Rodionov <vrodio...@carrieriq.com>wrote: > Is not this https://issues.apache.org/jira/browse/HBASE-6143? > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: vrodio...@carrieriq.com > > ________________________________________ > From: lars hofhansl [la...@apache.org] > Sent: Monday, July 22, 2013 4:04 PM > To: dev@hbase.apache.org > Subject: Re: Smarter Region assignment policy? > > Hmm... So that's an interesting bug then. Might filing a jira? > > -- Lars > > > > ----- Original Message ----- > From: Vladimir Rodionov <vrodio...@carrieriq.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl < > la...@apache.org> > Cc: > Sent: Monday, July 22, 2013 3:30 PM > Subject: RE: Smarter Region assignment policy? > > OK, you right and I was not. If I do not disable/enables tables after > cluster restart all regions seem get assigned correctly. > I think its disabling/enabling tables shuffles regions in a bad way. > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: vrodio...@carrieriq.com > > ________________________________________ > From: lars hofhansl [la...@apache.org] > Sent: Monday, July 22, 2013 12:13 PM > To: dev@hbase.apache.org; lars hofhansl > Subject: Re: Smarter Region assignment policy? > > This is the one: > https://issues.apache.org/jira/browse/HBASE-4402 > > > I assume you let the master wait sufficiently to give all RegionServer a > chance to sign in? > > -- Lars > ________________________________ > From: lars hofhansl <la...@apache.org> > To: "dev@hbase.apache.org" <dev@hbase.apache.org> > Sent: Monday, July 22, 2013 11:55 AM > Subject: Re: Smarter Region assignment policy? > > > I faintly remember there was a jira that attempted to assign the regions > to the same region servers after a restart based on existing .META. > information (if possible). > Will try to find that and see why it is not working as expected. > > > -- Lars > > > > ________________________________ > From: Vladimir Rodionov <vrodio...@carrieriq.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org> > Sent: Monday, July 22, 2013 11:43 AM > Subject: RE: Smarter Region assignment policy? > > > Yes, its related but not what I am looking for. > > Locality index is approaching to 100% after major compaction of all > tables. Its often > 90% during regular operation of a cluster, > but is far below 50% when cluster restarts. Can assignment manager take > into account previous region assignments on > node/cluster start up? That is what I am looking for. How hard is to > implement this feature? > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: vrodio...@carrieriq.com > > ________________________________________ > From: Ted Yu [yuzhih...@gmail.com] > Sent: Monday, July 22, 2013 11:06 AM > To: dev@hbase.apache.org > Subject: Re: Smarter Region assignment policy? > > Please take a look at https://issues.apache.org/jira/browse/HBASE-4755 > > On Mon, Jul 22, 2013 at 10:56 AM, Vladimir Rodionov < > vrodio...@carrieriq.com > > wrote: > > > It seems that current (0.94.6) region assignment on start up policy is > not > > that smart and does not utilize hdfs block locality > > Are there any open HBase JIRA ticket(s) that addresses the issue? > > > > Best regards, > > Vladimir Rodionov > > Principal Platform Engineer > > Carrier IQ, www.carrieriq.com > > e-mail: vrodio...@carrieriq.com > > > > > > Confidentiality Notice: The information contained in this message, > > including any attachments hereto, may be confidential and is intended to > be > > read only by the individual or entity to whom this message is addressed. > If > > the reader of this message is not the intended recipient or an agent or > > designee of the intended recipient, please note that any review, use, > > disclosure or distribution of this message or its attachments, in any > form, > > is strictly prohibited. If you have received this message in error, > please > > immediately notify the sender and/or notificati...@carrieriq.com and > > delete or destroy any copy of this message and its attachments. > > > > Confidentiality Notice: The information contained in this message, > including any attachments hereto, may be confidential and is intended to be > read only by the individual or entity to whom this message is addressed. If > the reader of this message is not the intended recipient or an agent or > designee of the intended recipient, please note that any review, use, > disclosure or distribution of this message or its attachments, in any form, > is strictly prohibited. If you have received this message in error, please > immediately notify the sender and/or notificati...@carrieriq.com and > delete or destroy any copy of this message and its attachments. >
