[ 
https://issues.apache.org/jira/browse/HBASE-10873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970373#comment-13970373
 ] 

Jimmy Xiang commented on HBASE-10873:
-------------------------------------

bq.  Today META/ns tables are already shared with the other tables, and there 
is little special treatment for the region server hosting meta. 
I think that's the issue we'd like to enhance. We want the region server 
hosting meta doesn't host too many heavy regions so that we can improve the 
meta availability, right?

bq. I think we should do a all-or-nothing approach rather that this weight 
based config which is just yet another parameter to worry about. 
Currently, we already support all or nothing. With this patch, it will make it 
more flexible so that users don't have to leave those backup masters totally 
idle, they don't need to worry too much about region movement/data locality in 
case each region server hosts many regions.



> Control number of regions assigned to backup masters
> ----------------------------------------------------
>
>                 Key: HBASE-10873
>                 URL: https://issues.apache.org/jira/browse/HBASE-10873
>             Project: HBase
>          Issue Type: Improvement
>          Components: Balancer
>            Reporter: Jimmy Xiang
>            Assignee: Jimmy Xiang
>             Fix For: 0.99.0
>
>         Attachments: hbase-10873.patch, hbase-10873_v2.patch
>
>
> By default, a backup master is treated just like another regionserver. So it 
> can host as many regions as other regionserver does. When the backup master 
> becomes the active one, region balancer needs to move those user regions on 
> this master to other region servers. To minimize the impact, it's better not 
> to assign too many regions on backup masters. It may not be good to leave the 
> backup masters idle and not host any region either.
> We should make this adjustable so that users can control how many regions to 
> assign to each backup master.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to