[
https://issues.apache.org/jira/browse/CASSANDRA-19948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885085#comment-17885085
]
Stefan Miklosovic edited comment on CASSANDRA-19948 at 9/26/24 4:41 PM:
------------------------------------------------------------------------
[~jmckenzie]
Interesting. So if I got it correctly, DatabaseDescriptor.isCDCEnabled() is a
vehicle which acts as if it was configured the same way on all nodes. We just
do not have a way to tell if a remote node recognizes that column or not when
schema modification is propagated.
Is not there another way how to bypass this? E.g. "extensions frozen<map<text,
blob>>" in system_schema.tables for 3.0? "extensions" are from 3.0 all the way
to trunk, we would just look into that instead in 3.0.
edit: well, since we do not know what node we are sending it to, we would need
to put it into "extension" for every node. But then this would be pretty
complicated during upgrade. One node including this logic, another would not,
now what ...
was (Author: smiklosovic):
[~jmckenzie]
Interesting. So if I got it correctly, DatabaseDescriptor.isCDCEnabled() is a
vehicle which acts as if it was configured the same way on all nodes. We just
do not have a way to tell if a remote node recognizes that column or not when
schema modification is propagated.
Is not there another way how to bypass this? E.g. "extensions frozen<map<text,
blob>>" in system_schema.tables for 3.0? "extensions" are from 3.0 all the way
to trunk, we would just look into that instead in 3.0.
edit: well, since we do not know what node we are sending it to, we would need
to put it into "extension" for everywhere. But then this would be pretty
complicated during upgrade. One node including this logic, another would not,
now what ...
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
