[
https://issues.apache.org/jira/browse/HBASE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428673#comment-16428673
]
Andrew Purtell commented on HBASE-20265:
----------------------------------------
I think the isolation requirements of your deployment implied by you wanting to
use RSGroups in the first place contradicts the idea of auto assign of tables
from a totally failed rsgroup to another. You've broken your isolation as soon
as you do that. And if the failed rsgroup went down because the tenant was
naughty, you've handed them license to take down the whole cluster.
I'm inclined to close this as Not A Bug. What do you think?
> 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)
