On Mon, Dec 20, 2010 at 10:32 PM, Mohit <[email protected]> wrote: > I call it static assignment, i.e. before putting it into regionInTransistion > and before load factor actually being considered. > > Correct me if I'm wrong, >
Sounds right. > This static assignment is based on the byte comparison result, whichever > meta region entry in onlineMetaRegions is closest but less than the supplied > user region value(computed byte) is returned, Am' I right on this? And why > such a design strategy? > Entries in .META. are stored sorted. > Ok, now, if say during region assignment , that particular Region Server > i.e. RS1 which hosts the meta region containing the above made entry is > loaded(or say at that time RS2 while sending empty message server report; > HMaster in turn replied with message MSG_REGION_OPEN for this user region) > and the user region is now assigned to another server RS2, then I assume > reassignment takes place, this inconsistency which Meta Scanner reports. > Regions moving on a cluster is 'normal'. Clients recalibrate to find new locations on RS2 say. > So I need to understand how this double assignment get resolved and also > while creating table a check if table already exists prone to fail, because > it always try to get the closest meta region which could possibly be holding > that region but it may be held by another meta table/region( say hosted on > RS2). > There is only one .META. table whereever it exists. The table is not replicated. > So Even if the table exists , it will proceed ahead without any exception. > Are you seeing an issue Mohit? Thanks for looking into this. St.Ack
