The sequence does have some objective benefits - especially stopping transports and then gossip, it tells everything you’re going offline before you do, so requests won’t get dropped or have to speculate to other replicas.
-- Jeff Jirsa > On Jan 7, 2018, at 7:22 PM, kurt greaves <k...@instaclustr.com> wrote: > > None are essential. Cassandra will gracefully shutdown in any scenario as > long as it's not killed with a SIGKILL. However, drain does have a few > benefits over just a normal shutdown. It will stop a few extra services > (batchlog, compactions) and importantly it will also force recycling of dirty > commitlog segments, meaning there will be less commitlog files to replay on > startup and reducing startup time. > > A comment in the code for drain also indicates that it will wait for > in-progress streaming to complete, but I haven't managed to find 1. where > this occurs, or 2. if it actually differs to a normal shutdown. Note that > this is all w.r.t 2.1. In 3.0.10 and 3.10 drain and shutdown more or less do > the exact same thing, however drain will log some extra messages. > > On 2 January 2018 at 07:07, Jing Meng <self.rel...@gmail.com> wrote: >> Hi all. >> >> Recently we made a change to our production env c* cluster (2.1.18) - >> placing the commit log to the same SSD where data is stored, which needs >> restarting all nodes. >> >> Before restarting a cassandra node, we ran the following nodetool utils: >> $ nodetool disablethrift && sleep 5 >> $ nodetool disablebinary && sleep 5 >> $ nodetool disable gossip && sleep 5 >> $ nodetool drain && sleep 5 >> >> It was "graceful" as expected (no significant errors found), but the process >> is still a myth to us: are those commands used above "sufficient", and/or >> why? The offical doc (docs.datastax.com) did not help with this operation >> detail, though "nodetool drain" is apparently essential. >
