[jira] [Commented] (HBASE-3833) ability to support includes/excludes list in Hbase

["Vishal Kathuria (JIRA)" <ji...@apache.org>]

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

Vishal Kathuria commented on HBASE-3833:
----------------------------------------

Copying comment history from facebook internal task:


Dhruba Borthakur - at 3:09pm on April 21st
andrew/matthew: do we need a discussion on how this feature needs to be designed?

1. There would be two files includes and excludes.
2. If a  machine is listed in excludes file, it shuts down the regionserver on that machine.
3. Region servers should start only on machines that are listed in the includes file.
4. a command line utility to modify/update the excludes/includes file.


Andrew Ryan - at 3:15pm on April 21st
We've wanted parity from the beginning. So yes, online decommissioning should be supported. I don't see any reason to do otherwise.

To Vishal's question, we wouldn't allow the node to join and migrate the regions. We just wouldn't allow it to join. Just shut the regionserver down. But, if a regionserver has active regions when it gets the decommission request, then it should gracefully reassign its regions and then shut down.


Nicolas Spiegelberg - at 3:20pm on April 21st I think we just want to deny requests and force a regionserver already online to close.  HBase just has a logical association with regions that is given upon onlining, stored in an HDFS file called META.  We save the state across a graceful restart, but will assign out those regions after a small startup period has passed without onlining.  Therefore, we don't benefit from trying to grab any state from the physical server itself.


Vishal Kathuria - at 3:28pm on April 21st Thanks guys.

One question is: 
if I move a server from includes to excludes, should that trigger online decommissioning and shut the machine down when decomissioning is done? or should we kick it out right away?

I think the former is better. Looks like we are all agreeing on that?

thanks






Adrian Potra - at 3:35pm on April 21st
 * changed the subscribers. Removed: Adrian Potra.


Vishal Kathuria - at 3:35pm on April 21st Sorry, I wrote my comment before I read Nicolas'

I see his point - since the Region Servers don't have persisted data (which is in HDFS), we don't loose much by kicking them out.

sounds reasonable to me.


Dhruba Borthakur - at 4:37pm on April 21st
@Nicolas: "but will assign out those regions after a small startup period has passed without onlining"  -- is it possible to avoid the small startup period mentioned above if the RS is decommissioned?


Nicolas Spiegelberg - at 5:43pm on April 21st
@Dhruba: agreed.  We should just see what 'bin/hbase-daemon.sh stop regionserver" does.  By my comment, I just meant to say that, if need be, we can actually just kick out the connection and do all the work on the master.  As a safeguard either way, we should rename that RS's log directory (if it exists).  This will forcibly cause the RS to die if something went awry.



> ability to support includes/excludes list in Hbase
> --------------------------------------------------
>
>                 Key: HBASE-3833
>                 URL: https://issues.apache.org/jira/browse/HBASE-3833
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, regionserver
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>
> An HBase cluster currently does not have the ability to specify that the master should accept regionservers only from a specified list. This helps preventing administrative errors where the same machine could be included in two clusters. It also allows the administrator to easily remove un-ssh-able machines from the cluster.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira