[
https://issues.apache.org/jira/browse/HBASE-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479450#comment-16479450
]
Andrew Purtell commented on HBASE-20595:
----------------------------------------
bq. we'll probably need to document "can't turn on rsgroup feature" as a
limitation of single-node deployments.
Ah, no, better that the constraint that system tables cannot be placed into the
same rsgroup as user tables be what is optional.
> Remove the concept of 'special tables' from rsgroups
> ----------------------------------------------------
>
> Key: HBASE-20595
> URL: https://issues.apache.org/jira/browse/HBASE-20595
> Project: HBase
> Issue Type: Task
> Components: Region Assignment, rsgroup
> Reporter: Andrew Purtell
> Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0
>
>
> Regionserver groups needs to specially handle what it calls "special tables",
> tables upon which core or other modular functionality depends. They need to
> be excluded from normal rsgroup processing during bootstrap to avoid circular
> dependencies or errors due to insufficiently initialized state. I think we
> also want to ensure that such tables are always given a rsgroup assignment
> with nonzero servers. (IIRC another issue already raises that point, we can
> link it later.)
> Special tables include:
> * The system tables in the 'hbase:' namespace
> * The ACL table if the AccessController coprocessor is installed
> * The Labels table if the VisibilityController coprocessor is installed
> * The Quotas table if the FS quotas feature is active
> Either we need a facility where "special tables" can be registered, which
> should be in core. Or, we institute a blanket rule that core and all
> extensions that need a "special table" must put them into the 'hbase:'
> namespace, so the TableName#isSystemTable() test will return TRUE for all,
> and then rsgroups simply needs to test for that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
