[ 
https://issues.apache.org/jira/browse/CASSANDRA-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759008#action_12759008
 ] 

Jon Mischo commented on CASSANDRA-44:
-------------------------------------

Adding JMX commands to manage CFs doesn't have to be evil, provided we 
distribute the information to all nodes and they serialize a new config out to 
disk.  If the config change has a serial and a checksum that is sent to every 
node, the xml config can be stamped with them, and any node with an old or 
corrupt config could pull the latest config during bootstrapping on restart or 
after failed validation against checksum.

Just an idea, but it's one that solves for the "invisible" configuration issue 
and adds manageability without sacrificing uptime.  Since adding and removing 
CFs should be a rare event, I don't think we need to designate a single point 
of failure to be the "authoritative" node for the config, though the first node 
to get the config change could be the one responsible for gaining consensus on 
the "current" configuration and then also be responsible for generating the new 
serial and checksum.

The real question in my mind is whether this is something that we require a 
management tool to contact every node via JMX for, or whether a success message 
from a single node means it's already successfully distributed the 
configuration change to N nodes/quorum/all nodes.

> It is difficult to modify the set of ColumnFamliies in an existing cluster
> --------------------------------------------------------------------------
>
>                 Key: CASSANDRA-44
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-44
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Eric Evans
>             Fix For: 0.5
>
>
> ColumnFamilies may be added when cassandr is not running by editing the 
> configuration file.
> If you need to delete or re-order CFs, you must
> 1) kill cassandra
> 2) start it again and wait for log replay to finish
> 3) kill cassandra AGAIN
> 4) make your edits (now there is no data in the commitlog)
> 5) manually remove the sstable files (-Data.db, -Index.db, and -Filter.db) 
> for the CFs you removed, and rename files for CFs you renamed
> 6) start cassandra and your edits should take effect

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to