[
https://issues.apache.org/jira/browse/HBASE-20265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428674#comment-16428674
]
Andrew Purtell commented on HBASE-20265:
----------------------------------------
System tables shouldn't be hosted with user tables in an rsgroup deployment, so
we can take advantage of the resource isolation (with the trade off that the
group for system tables needs to be large enough, e.g. allocate N+1 servers to
this group to tolerate N concurrent host failures, and try to allocate them
from separate failure domains (separate racks)). This could be added to docs as
suggested practice.
> 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)
