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