[
https://issues.apache.org/jira/browse/CASSANDRA-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984948#action_12984948
]
Peter Schuller commented on CASSANDRA-2026:
-------------------------------------------
This may be me over-estimating the chances of this being the same problem
because it's fresh in my mind, but the symptoms seem similar to CASSANDRA-2015
- is it possible schema changes were submitted concurrently/close to each other
(prior to previous propagating) on multiple nodes?
I saw both that propagation would be incomplete, and that once it got stuck it
would reliably be stuck in the sense that migrations submitted on one node
would reliably not reach a certain set of other nodes (but in this case
extrapolated from a small 3 node cluster).
> 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
> Assignee: Gary Dusbabek
> Priority: Blocker
> 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.
