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. >
