[
https://issues.apache.org/jira/browse/CASSANDRA-19948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884633#comment-17884633
]
Stefan Miklosovic commented on CASSANDRA-19948:
-----------------------------------------------
There is the opposite side of this (1). Before 5.1 (or, up to 5.0), there is
not TCM, so all schema changes are sent as (CQL) Mutations. Basically, a row
from CQL (because all schemas are in system_schemas and similar), is
transformed into a Mutation (stuff you go to ultimately write into the DB,
holds for any modification really) and this Mutation is serialized and sent
over by internode messaging. On the other side, when it comes to a node which
reacts on schema changes, that Mutation will be transformed to a Row and we
construct TableParams from that Row. If you notice, in (1), there is memtable
check, a row which came to that node has a memtable column, it will be used,
otherwise if it is not specified, the default will be used.
So for example, when 4.0 node sends a mutation, it comes to this and because
memtable was not specified, it will use default. However when a mutation comes
from 4.1, such mutation will have memtable column and it will use that one.
Similarly for allow_auto_snapshot, if 4.0 sends a mutation and it comes to
this, allow_auto_snapshot column will not be there, so nothing will be set.
CDC seems to be different because it is derived from cassandra.yaml rather than
from the schema itself.
https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1065-L1071
> Changing cdc table property can cause schema disagreement
> ---------------------------------------------------------
>
> Key: CASSANDRA-19948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19948
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
> Reporter: Bowen Song
> Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: 4.1.1.txt, 4.1.6.txt, 5.0.0-corrected.txt,
> cdc_schema_disagreement.sh
>
>
> In the cassandra.yaml file, there is a parameter named "cdc_enabled" which
> allows CDC to be enabled or disabled on each individual nodes.
> It has been found that it can cause schema disagreement or discrepancy when
> an "ALTER TABLE ... WITH cdc=..." statement is ran against a node which has
> "cdc_enabled" set to "false" in a cluster in which nodes have mixed
> "true"/"false" values for the "cdc_enabled" settings.
> The exact behaviour of the above is version-dependant.
> On Cassandra 4.1.1, the cluster will end up in the schema disagreement state.
> A rolling restart will bring the schema back in sync, but the changes made to
> the `cdc` table property will be lost.
> On Cassandra 4.1.6, the cluster will not have visible schema disagreement in
> the "nodetool describecluster" command's output, but the "ALTER TABLE"
> statement only has cosmetic effect on the node it is run. The node with
> "cdc_enabled" set to "false" will show the "cdc" table property has changed,
> but this does not affect its behaviour in any way. At the same time, other
> nodes do not see that table property change at all. This is perhaps even
> worse than on 4.1.1, because the alter table statement is silently failing.
> On Casandra 5.0.0, the behaviour is the same as 4.1.6.
> A shell script for reproducing the above described behaviours in Docker, and
> the outputs of it on both 4.1.1 and 4.1.6 and 5.0.0 are attached.
>
> Edit on 25 Sep: added test result on 5.0.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
