accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1454) Need good way to perform a rolling restart of all tablet servers
Date Tue, 12 Aug 2014 15:55:13 GMT

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

Josh Elser commented on ACCUMULO-1454:
--------------------------------------

bq. If we expose a user level command to request that a tablet be moved to a given destination

Do we necessarily care where they move? I don't have a good feel for the difference in cost
between moving to a "sibling" tserver on the same node as opposed to a tserver on a completely
different node. We also might just be fighting the balancer if we make it seem like the user
has control over where a tablet is hosted. HBase has such a tool, no? Can we glean anything
from their rolling upgrade support (good and bad)?

> 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: Improvement
>          Components: tserver
>    Affects Versions: 1.4.3, 1.5.0
>            Reporter: Mike Drob
>
> 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.2#6252)

Mime
View raw message