[
https://issues.apache.org/jira/browse/CASSANDRA-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848394#action_12848394
]
Jonathan Ellis commented on CASSANDRA-44:
-----------------------------------------
Was going to put this on a comment to CASSANDRA-826 but maybe here is better.
How do we deal with the rename partition problem?
that is, say we rename a CF A -> B, then create a new A (A'). Some node N is
down for the rename.
Now N comes back up while clients are inserting into A'. N will happily insert
them to A, then rename A -> B when it gets news of the update.
AFAICS this is an issue under either push or pull schema propagation.
I see a couple options:
1. only allow schema changes when 100% of nodes are up. This is both
limiting (when you get to 100s of nodes it could be pretty inconvenient) and
buggy (a node could be up when you start the update, but go down before it's
complete; FD is not instant).
2. disallow renames, only allow add and drop
3. allow renames, but only allow reusing an old CF name once the entire
cluster has completed the first rename (so kind of 1., but only apply the 100%
rule in this one corner case)
Are there other options? I'm trying to think of a way that having a ZK
ensemble would give us a magic wand here, as originally envisioned, but I don't
see one (short of having nodes ask ZK for schema definitions on every op, which
is unacceptable for performance). So I think my inclination would be to start
w/ (2) and then add (3).
> 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
> Assignee: Gary Dusbabek
> Fix For: 0.7
>
>
> 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.
