Hello Guys,

 

While creating table, a function call getFirstMetaRegionForRegion() to fetch
the meta region which should contain the user table region, after then the
query to that particular meta-region is made to check if  the table already
exists, else the table is new and a RegionInfo entry being made into that
particular meta table, say hosted on RS1, 

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, 

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?

 

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.

 

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).

 

So Even if the table exists , it will proceed ahead without any exception.

 

-Mohit

 

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

 

Reply via email to