[
https://issues.apache.org/jira/browse/CASSANDRA-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985899#action_12985899
]
Matthew F. Dennis commented on CASSANDRA-2026:
----------------------------------------------
If you must call describe_versions until it matches otherwise the cluster
breaks, then the call you make to change schema should do this for you. If
after some reasonable amount of time (or whatever you pass into the call) there
still isn't schema agreement, then the call can return with an error/exception.
I could easily be convinced the API itself shouldn't do this, but the CLI
certainly should. When the call returns from the CLI, I expect my request to
completely finished and things working or I expect the CLI to return an error.
This applies to invocations in batch mode, in file mode and in interactive mode.
> 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.
