[
https://issues.apache.org/jira/browse/CASSANDRA-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-2026.
---------------------------------------
Resolution: Won't Fix
Assignee: (was: Gary Dusbabek)
Even making it block wouldn't fix the corner cases (timeout due to latency /
load / crashes); fundamentally, Thou Shalt Call describe_versions After
Updating Schema Until Thy Versions Match, or Thy Cluster Shall Break.
> creating/dropping keyspaces does not work reliably
> --------------------------------------------------
>
> Key: CASSANDRA-2026
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2026
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0
> Environment: observed on EC2 and real HW
> Reporter: Matthew F. Dennis
> Fix For: 0.7.1
>
>
> Creating and/or dropping keyspaces on more than just a few nodes does not
> reliably work (observed multiple times on 5, 15 and 40 node clusters. never
> observed on single node clusters)
> Right after a cluster is booted, importing a schema from yaml works reliably.
> However, creating keyspaces (same for dropping keyspaces) via the CLI, either
> with -f or by pasting into the window usually does not work (though sometimes
> it does). In particular, only some nodes show the new changes while others
> do not. ;
> Often the changes are only reflected on the node where they were made, but
> not on any other node. Most of the time some small subset of the nodes get
> the changes, but the majority do not.
> Sometimes it takes several attempts to expose the problem. Once it happens
> the first time though, it continues to happen reliably on every change after
> the problem is first observed.
> In most cases all changes were executed from the same seed node. It also
> happens when executed from non-seed nodes though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
