[
https://issues.apache.org/jira/browse/HBASE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16411542#comment-16411542
]
Dave Latham commented on HBASE-20265:
-------------------------------------
The purpose in my mind of rs groups is to be able to enforce strong isolation.
If something about user table 1 is taking down any region server that hosts it,
the last thing we would want to do is move it into a new rs group and affect
other tenants.
It sounds like like the right answer here would be to keep the system tables in
a separate rs group from the user tables.
> Host regions in other rsgroup when all region servers in a rsgroup are all
> down
> -------------------------------------------------------------------------------
>
> Key: HBASE-20265
> URL: https://issues.apache.org/jira/browse/HBASE-20265
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
> Reporter: Xiang Li
> Priority: Critical
>
> We met the following scenario in our production system:
> rsgroup A hosts user table 1 as well as system tables (let's say
> hbase:rsgroup, or hbase:meta). Several heavy reads on user table 1 make all
> region servers within rsgroup A crash. As a result, the system tables have no
> host.
> Under such scenario, we could manually move the system tables to another
> rsgroup.
> But what about:
> We provide an affinity or last resort. When all region servers in rsgroup A
> crash, rsgroup B, as rsgroup A's affinity, will take over all tables of
> rsgroup A, or at least, some important tables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
