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 <> 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 ( did not help with this
> operation detail, though "nodetool drain" is apparently essential.

Reply via email to