[jira] [Comment Edited] (ACCUMULO-1454) Need good way to perform a rolling restart of all tablet servers

["Josh Elser (JIRA)" <ji...@apache.org>]

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

Josh Elser edited comment on ACCUMULO-1454 at 2/17/15 5:05 PM:
---------------------------------------------------------------

Yes, you are correct. Thanks for commenting. We'll need to do some brainstorming as to what we'll need to add to the RPC api to support it -- the above concern will likely be pulled there. I just wanted to make sure I write it down so it doesn't get lost. (Opened ACCUMULO-3598)


was (Author: elserj):
Yes, you are correct. Thanks for commenting. We'll need to do some brainstorming as to what we'll need to add to the RPC api to support it -- the above concern will likely be pulled there. I just wanted to make sure I write it down so it doesn't get lost.

> Need good way to perform a rolling restart of all tablet servers
> ----------------------------------------------------------------
>
>                 Key: ACCUMULO-1454
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1454
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: tserver
>    Affects Versions: 1.4.3, 1.5.0
>            Reporter: Mike Drob
>         Attachments: ACCUMULO-1454-proposal-01.adoc, ACCUMULO-1454-proposal-01.html
>
>
> When needing to change a tserver parameter (e.g. java heap space) across the entire cluster, there is not a graceful way to perform a rolling restart.
> The naive approach of just killing tservers one at a time causes a lot of churn on the cluster as tablets move around and zookeeper tries to maintain current state.
> Potential solutions might be via a fancy fate operation, with coordination by the master. Ideally, the master would know which servers are 'safe' to restart and could minimize overall impact during the operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)