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