cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-2026) creating/dropping keyspaces does not work reliably
Date Fri, 21 Jan 2011 21:23:44 GMT


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

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

View raw message