Cassandra hot keyspace structure change

Question

I'm currently running a 12-node Cassandra cluster storing 4TB of data, with a replication factor set to 3. For the needs of an application update, we need to change the configuration of our keyspace, and we'd like to avoid any downtime if possible.

I read on a mailing list that the best way to do it is to:

1. Kill cassandra process on one server of the cluster
2. Start it again, wait for the commit log to be written on the disk, and kill it again
3. Make the modifications in the storage.xml file
4. Rename or delete files in the data directories according to the changes we made
5. Start cassandra
6. Goto 1 with next server on the list

My questions would be:

• Did I understand the process well?
• Is there any risk of data corruption?
• During the process, there will be servers with different versions of the storage.xml file in the same cluser, same keyspace. Is it a problem?
• Same question as above if we not only add, rename and remove ColumnFamilies, but if we change the CompareWith parameter / transform an existing column family into a super one. Or do we need to change the name?

Thank you for your answers. It's the first time I'll do this, and I'm a little bit scared.

Answer 1

Your list looks like the one in http://wiki.apache.org/cassandra/FAQ#modify_cf_config. So it should be accurate...