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-4061) Add way to determine Accumulo version from a running tserver
Date Fri, 20 Nov 2015 17:53:11 GMT

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

Josh Elser commented on ACCUMULO-4061:
--------------------------------------

That sounds like a good idea. Including that in the metrics to populate the TabletServer page
on the monitor (Hosted Tablets, Last Contact, Entries, Ingest, Query, Hold Time, Running,
Scans, Minor, Compactions, Major, Compactions, Index Cache, Hit Rate, Data Cache, Hit Rate,
OS Load) would likely be pretty straightforward.

> Add way to determine Accumulo version from a running tserver
> ------------------------------------------------------------
>
>                 Key: ACCUMULO-4061
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4061
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: tserver
>            Reporter: Ed Coleman
>            Priority: Minor
>             Fix For: 1.8.0
>
>
> When upgrading by performing a rolling restart, realized that there was no way to determine
the version of a running tserver other than using ps to get start time or maybe a versioned
package on the classpath.
> A typical deployment structure seems to be lay down the Accumulo directories with a version
and then use a symbolic link to point to the version that is used at run-time. As an example:
> /usr/local/accumulo
> /usr/local/accumulo/accumulo-1.6.2
> /usr/local/accumulo/accumulo-1.6.3
> /usr/local/accumulo/accumulo-latest --> /usr/local/accumulo/accumulo-1.6.3
> To upgrade without a complete shutdown, we lay down the new version, update the symbolic
link and then perform a rolling restart of the tservers, with scripts, env,... using the symbolic
link to specify which version are used.
> Realized that if the rolling shutdown failed for any particular tserver, it would keep
running the previous version.  The only way to determine if we were running the desired version
was to use ps and check the running time of the tserver process.
> The could also be a situation were a "dead" server would be offline during the upgrade
and not receive the new version. If the server was resurrected and services started before
updated versions are installed it could be difficult to determine exactly what version of
the tserver was running. 
> It would be nice if there was some way to ask a running tserver what version it is. That
way, post-upgrade we could confirm that all running tservers reply with the expected version.



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

Mime
View raw message