Thank you for reporting this. I may check next week more closely and let you know.
On Fri, Sep 20, 2024 at 5:43 PM Bowen Song via user < user@cassandra.apache.org> wrote: > Hi all, > > I suspect that I've ran into a bug (or two). > > On Cassandra 4.1.1, when `cdc_enabled` in the cassandra.yaml file is set > to `false` on at least one node in the cluster, and then the `ALTER > TABLE ... WITH cdc=...` statement was run against that node, the cluster > will end up in the schema disagreement state. At this stage, 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 same procedure doesn't cause 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. > > A shell script for reproducing the above described behaviours, and the > output on both 4.1.1 and 4.1.6 are attached. > > (as a good security practice, please always read and understand the full > script you downloaded from untrusted sources before attempting to run it) > > So, are these bugs? Or is this some kind of behaviour that's documented > but I failed to find that documentation for? > > Cheers, > Bowen >
