[
https://issues.apache.org/jira/browse/HBASE-20566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477976#comment-16477976
]
Nihal Jain commented on HBASE-20566:
------------------------------------
Hi all, I will try to answer as much as I can.
{quote} Will the change handle the scenario where {{hbase}}namespace is
assigned to a non {{default}} namespace by the user before enabling {{Quota}}?
Or the requirement/assumption is that {{hbase}} namespace should be in
{{default}} namespace.
{quote}
[~gsbiju] This change should not impact the above mentioned scenario. I will
try to explain shortly.
{quote}does this affect 2.0 as well? should we apply the patch to older
branches?
{quote}
[~mdrob] Yes 2.0 also has the same problem. I have tested locally.
{quote}Does this affect the branch-1 port of RSgroups too?
{quote}
[~apurtell] Since the refresh() logic is same, I think yes.
{quote}Ain't it odd having rsgroup keeping a running group of 'special' tables?
{quote}
[~stack] Based on my understanding, I will try to answer what does special
tables mean. Let me first explain what refresh() method will do when a user
starts hbase with rs-groups for the first time i.e. none of the tables belong
to any rs-group:
* {{RSGroupAdminEndpoint}} calls {{start()}} which creates a new
{{groupInfoManager}} instance
** The {{getInsatnce()}} will call {{init()}} method
*** {{init}} calls {{refresh()}}
**** {{refresh()}} calls {{refresh(false)}} which refreshes group information
*
{code:java}
groupInfoManager = RSGroupInfoManagerImpl.getInstance(master);
--> instance.init();
----> refresh();
------> refresh(false);{code}
Now {{refresh()}} method refreshes/reloads group information of all tables from
the persistent storage (doc says this) i.e.
* refresh all-table group info from zk/rs-group table (if available)
* create a list of orphan tables which will ultimately contain tables which
are not assigned to any rs-group (first run?)
** add all tables whose descriptors are available in fs to orphan table
** add all "special tables" to special table list
** remove all tables which have some rs-group from orphan list ([~gsbiju] yes
it should handle it here)
* update rs-group of final orphan table list to be default
So what are these special tables?
* from what I understand, special tables are those tables which may not have
been created until the current start-up of cluster (whose creation is in
progress?), so might not be found in descriptors from fs ("hbase:quota"?)
* As these tables must be loaded with priority, they have been handled in this
way (i.e. if first run, they get assigned to default rs-group, so that
{{CreateTableProcedure}} doesn't hang), which seems a bad way of doing (what if
some new co-processor tries to create a new system table at startup =>
assignment hangs as no rs-group for this table; not handled as special table)
I think we need to figure out how to handle "{{specialTables"}} in a more
generic manner.
(NOTE: I am new here, correct me wherever I am wrong :P)
> Creating a system table after enabling rsgroup feature puts region into RIT
> ---------------------------------------------------------------------------
>
> Key: HBASE-20566
> URL: https://issues.apache.org/jira/browse/HBASE-20566
> Project: HBase
> Issue Type: Bug
> Components: master
> Reporter: Biju Nair
> Assignee: Nihal Jain
> Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20566.master.001.patch,
> HBASE-20566.master.002.patch
>
>
> *Steps to reproduce*
> - Enable {{rsgroup}} feature
> - Enable {{quota}} feature which created {{hbase::quota}} table
> - quota table region will be marked as RIT since the {{rsgroup}} for the
> table is not known
> {noformat}
> 2018-05-10 14:33:32,392 INFO [ProcedureExecutorThread-0]
> zookeeper.ZKTableStateManager: Moving table hbase:quota state from null to
> ENABLING
> 2018-05-10 14:33:32,397 WARN [ProcedureExecutorThread-0]
> rsgroup.RSGroupBasedLoadBalancer: Group for table hbase:quota is null
> 2018-05-10 14:33:32,398 WARN [ProcedureExecutorThread-0]
> master.RegionStates: Failed to open/close 89490cd5e00ea8948af413a1df65091a on
> null, set to FAILED_OPEN
> 2018-05-10 14:33:32,398 INFO [ProcedureExecutorThread-0]
> master.RegionStates: Transition {89490cd5e00ea8948af413a1df65091a
> state=OFFLINE, ts=1525977212397, server=null} to
> {89490cd5e00ea8948af413a1df65091a state=FAILED_OPEN, ts=1525977212398,
> server=null}
> 2018-05-10 14:33:32,398 INFO [ProcedureExecutorThread-0]
> zookeeper.ZKTableStateManager: Moving table hbase:quota state from ENABLING
> to ENABLED
> {noformat}
> - Reason for this issue: Issue
> - [system table
> creation|https://github.com/apache/hbase/blob/061a31fad1654d9ded96d118e04c14860413fa25/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java#L1793]
> doesn't move the table to the appropriate rs group to which system namespace
> is assigned to. Need to execute logic similar to what is done in the
> RSGroupAdminEndpoint for [post table creation|#L377] for user table creation.
> *Work Around*
> - Assigning the system table to ``default`` rsgroup (or to the rsgroup to
> which the system namespace has been assigned).
> - Manually assigning the region in RIT from the system table
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
