I've always assumed that when the drain command logs that the node is drained 
the commit log is clear. The drain command stops the node from accepting 
requests, flushes the memtables to disk and finally marks the commit logs as 
safe to delete. As far as I can tell, it should either work or fail. 

If a second of the log cannot be discard the command will log at debug level 
"Not safe to delete commit log...". But AFAIK once the memtables are flushed 
and more more writes accepted you are good to go. 

If you are dropping CF's then you should be able to deploy the code to stop 
querying them and then do a rolling change in the cluster. If you are renaming 
then it may be a bit trickier.

Shutting down with kill -9 is the approved way to stop cassandra. 

Also, am assuming you are on 0.6*.
Hope that helps
Aaron


On 13 Oct 2010, at 21:00, Jean-Yves LEBLEU wrote:

> Hi all,
> 
> When I look at the wiki the procedure to change the column family is :
> 
> Empty the commitlog with "nodetool drain."
> Shutdown Cassandra and verify that there is no remaining data in the 
> commitlog.
> Delete the sstable files (-Data.db, -Index.db, and -Filter.db) for any CFs 
> removed, and rename the files for any CFs that were renamed.
> Make necessary changes to your storage-conf.xml.
> Start Cassandra back up and your edits should take effect.
> 
> 
> How do we check that the commitlog is empty ? as it seems that there are 
> still files in the commit log directory after a drain ?
> 
> Is it necessary to shutdown all nodes in a ring before changing the 
> storage-conf.xml files ?
> 
> On linux is a "kill -9" acceptable as a cassandra shutdown ?
> 
> Thanks for answer.
> 
> Jean-Yves

Reply via email to