----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24855/#review74840 -----------------------------------------------------------
Was thinking about this some more today again. docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc <https://reviews.apache.org/r/24855/#comment121624> Disabling tablet assignment across the cluster could have unintended negative consequences. If a tabletserver dies during a rolling upgrade, the tablets its hosting would be unavailable until that server is restarted as a part of the rolling upgrade script. For large numbers of tservers, that could be an extended outage. It would be better if we could identify some batch of tabletservers, mark all tablets currently hosted on those tablet servers as "disabled", and prevent any migrations to those servers. This would allow the rest of the cluster to continue to operate as normal, while avoiding reassignment churn on the nodes being restarted. It would be more difficult to implement in the master than simply disabling assingment completely. We might be able to do it fairly easily with a new value in TabletGoalState, but that's only after a very naive look at the code recently. docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc <https://reviews.apache.org/r/24855/#comment121623> I have no idea how it was done, but I found myself lamenting that we couldn't somehow let the master restart a tabletserver instead of just shutting it down. That would alleviate the shell-scripting burden, but I can't think of a way to actually make that happen. I'm going to look at what HBase has for their scripting of RU. docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc <https://reviews.apache.org/r/24855/#comment121622> Maybe it would be better to create an Enum for "assignment state". The first two values in this enum would be "DISABLE", "ENABLE". This would give us some more flexibility in supporting additional states in the future, although I can't directly come up with a concrete example. - Josh Elser On Aug. 21, 2014, 8:12 p.m., kturner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/24855/ > ----------------------------------------------------------- > > (Updated Aug. 21, 2014, 8:12 p.m.) > > > Review request for accumulo. > > > Bugs: ACCUMULO-1454 > https://issues.apache.org/jira/browse/ACCUMULO-1454 > > > Repository: accumulo > > > Description > ------- > > Positing ACCUMULO-1454 design doc for review > > > Diffs > ----- > > docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc PRE-CREATION > > Diff: https://reviews.apache.org/r/24855/diff/ > > > Testing > ------- > > > Thanks, > > kturner > >