[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881823#comment-16881823
]
vincent royer commented on CASSANDRA-10699:
---
Currently (in v3.11.4), each DDL statement involves a schema mutation, and you
cannot validate a statement without applying the previous one (ex: CREATE TYPE
A, CREATE TYPE B, CREATE TABLE (a A, b B)), As the result, a DDL script
generate a storm of single schema updates for all nodes rather than a batched
schema update.
If it can help, we have done some improvements in our cassandra to manage batch
schema update in a transaction. This means that we can validate several schema
changes on a working copy of the current schema and apply these changes in one
update broadcasted to all nodes (one mutation for several DDL statements).
We've done that for Elassandra, and Elassandra also plays a PAXOS transaction
to update the elasticsearch mapping, so CQL schema updates resulting of an
Elasticsearch mapping update are serialized, and applied in one batch update
after validation on a working copy of the schema. It does not fully solve this
issue for Cassandra, but it solves it when you update the CQL schema through
the Elasticsearch mapping.
Here is our commit about that work available on
[commit1|https://github.com/strapdata/cassandra/commit/d7b7844a6d25f7d42d68e4abd1d89c4e92049545]
[commit2|https://github.com/strapdata/cassandra/commit/46cfaa8ac158f4e35078265667e3574719117eb3]
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881237#comment-16881237
]
Sumanth Pasupuleti commented on CASSANDRA-10699:
[~iamaleksey] could you please update on what the latest status of this ticket
is.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Distributed Metadata
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452069#comment-16452069
]
Aleksey Yeschenko commented on CASSANDRA-10699:
---
bq. With this change, will schema alterations be versioned? I think this would
be helpful when plugging in other storage engines.
Yes, keyspace-scoped.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16451647#comment-16451647
]
Brian O'Neill commented on CASSANDRA-10699:
---
With this change, will schema alterations be versioned? I think this would be
helpful when plugging in other storage engines. [#CASSANDRA-13474]
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 4.0
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035164#comment-16035164
]
Aleksey Yeschenko commented on CASSANDRA-10699:
---
bq. btw the original assignee change was not intentional.
No worries. If you love it put a ring on it and all that.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 4.0
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035133#comment-16035133
]
Aleksey Yeschenko commented on CASSANDRA-10699:
---
bq. In particular I'm interested in how to avoid concurrent schema changes
causing problems. Aleksey Yeschenko Is the plan to use Paxos to linearise the
schema changes?
Paxos, yes. Though not directly through our LWT implementation.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
> Fix For: 4.0
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035130#comment-16035130
]
Matt Byrd commented on CASSANDRA-10699:
---
In particular I'm interested in how to avoid concurrent schema changes causing
problems.
[~iamaleksey] Is the plan to use Paxos to linearise the schema changes?
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
>Assignee: Matt Byrd
> Fix For: 4.0
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16035114#comment-16035114
]
Aleksey Yeschenko commented on CASSANDRA-10699:
---
[~mbyrd] FYI this is in progress, close to done, ish. Two more dependencies
need to be resolved before then - CASSANDRA-13426 - currently in review by Sam
- and moving the protocol away from mutations (in progress, no JIRA for it).
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
>Assignee: Matt Byrd
> Fix For: 4.0
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15287591#comment-15287591
]
Tyler Hobbs commented on CASSANDRA-10699:
-
This will not be backported to 2.2. It will only be in 3.x, at the earliest.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15287500#comment-15287500
]
Tom Petracca commented on CASSANDRA-10699:
--
Are there any plans to be able to backport this to 2.2 or is it safe to assume
that this (and the other schema hardening issues in 9424) will only hit 3.X and
beyond?
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187068#comment-15187068
]
Aleksey Yeschenko commented on CASSANDRA-10699:
---
bq. Will resolution of this ticket enable concurrent clients to successfully
perform CREATE TABLE IF NOT EXISTS? Or will that still be problematic? I just
want to know if this is the ticket to point people to for concurrent CREATE
TABLE IF NOT EXISTS issues.
Yes. But I'm not sure why you are singling out the {{IF NOT EXISTS}} case. Both
plain {{CREATE TABLE}} and {{CREATE TABLE IF NOT EXISTS}} require strongly
consistent schema to work 100% correctly.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116229#comment-15116229
]
Jack Krupansky commented on CASSANDRA-10699:
Will resolution of this ticket enable concurrent clients to successfully
perform CREATE TABLE IF NOT EXISTS? Or will that still be problematic? I just
want to know if this is the ticket to point people to for concurrent CREATE
TABLE IF NOT EXISTS issues.
In the mean time, should we update the doc to effectively say that concurrent
CREATE TABLE IF NOT EXISTS is not supported and that it is the responsibility
of the user to absolutely refrain from attempting any potentially concurrent
attempts to CREATE TABLE IF NOT EXISTS for a given table?
A related doc issue is how the user can tell that the CREATE TABLE has
successfully completed around the ring. IOW, if cqlsh returns success, is the
table really created on all nodes? Is a nodetool tablestats a reliable check -
if all nodes are listed then the CREATE TABLE has succeeded/completed on all
nodes?
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10699) Make schema alterations strongly consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006857#comment-15006857
]
Jim Witschey commented on CASSANDRA-10699:
--
Just so developers working on this know: until we build a system for viewing
test results and filtering out known failures, we are skipping the dtests in
{{concurrent_schema_changes_test.py}} with {{@require(10699)}}.
> Make schema alterations strongly consistent
> ---
>
> Key: CASSANDRA-10699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10699
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Aleksey Yeschenko
> Fix For: 3.x
>
>
> Schema changes do not necessarily commute. This has been the case before
> CASSANDRA-5202, but now is particularly problematic.
> We should employ a strongly consistent protocol instead of relying on
> marshalling {{Mutation}} objects with schema changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
