cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-44) It is difficult to modify the set of ColumnFamliies in an existing cluster
Date Tue, 22 Dec 2009 17:26:29 GMT


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

View raw message