[
https://issues.apache.org/jira/browse/CASSANDRA-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793682#action_12793682
]
Jonathan Ellis commented on CASSANDRA-44:
-----------------------------------------
Latest thoughts:
Other things being equal, I would prefer to provide a thrift interface to
add/rename/remove keyspace and CFs through a single coordinator node (vs having
to update each node via JMX, or push out a new config file). Keeping things
config-file based has two drawbacks:
- it requires filesystem access for whoever is doing the update, which is
problematic in some environments
- it makes life difficult for systems building on top of cassandra that want
to automate this (easy for a human to dsh scp from somewhere; possible, but
painful, to integrate this into an automated system that is more than a one-off)
- it requires either all nodes being up for the upgrade, which is simple but
unrealistic, or ops manually re-pushing the update to nodes that are down,
which is a pita
So if we can instead move to a system where KS/CF definitions are stored in a
system CF and updated programatically, I think that would be best.
Possible evolution of the code might look like
(1) move KS/CF definitions into the system table
(2) add schema change methods internally and tests (possibly expose via JMX
for manual testing, but not nodeprobe)
(3) add thrift interface to send schema changes out to other nodes
(4) add gossip of MetadataVersion (a user provided? automatically generated?
identifier string): gossip automatically handles updating nodes that were down
on what happened while they were out. Full schema will not fit in gossip but a
version id will. A node whose internal MV is lower than one it sees in gossip,
should ask the node w/ the higher version to send it the new version.
(Remember we cannot rely on HH for this since the FD may not have recognized
that the node was down when the update was happening).
We punt completely on two clients requesting conflicting changes from different
coordinator nodes. "Don't do that." (Just as copying out two conflicting
config files is Bad.)
One possible layout for the metadata CFs:
migrations: hardcoded key of "migrations": each column w/ name of
MetadataVersion contains the op performed
schema: key of MV, supercolumns of KS, columns of serialized CF definitions
so on startup, we read latest MV from migrations row, then the associated
schema.
(Looked at this way it seems like we should just have MV be a TimeUUID and not
make client deal w/ that.)
> 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.9
>
>
> 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
> Alternatively on Cassandra 0.4.2 or later:
> 1) run nodeprobe flush and wait for it to finish
> 2) kill cassandra
> Then:
> 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.
