Yeah; think that would need to live in `AlterTableStatement.java` in probably `#AlterOptions`. There's guardrail validation in there for gc_grace, mv's, replication strategies, and compression on 4.1 but I'm not seeing any guardrail for CDC.
Could you open a JIRA for that Bowen? Might even be other params that we can enable/disable on the node level we're not checking in the guardrails on alter; CDC predated guardrails so this might be an isolated oversight but /shrug. On Mon, Sep 23, 2024, at 11:06 AM, Josh McKenzie wrote: > I wouldn't be surprised if we don't have logic in place to handle that > disjoint (DDL for disabled .yaml property) at least in the case of CDC. It's > been the better part of a decade since that first impl but I don't have any > recollection of that logic being in there. > > Let me take a quick look at the code and I'll get back to you; might need a > JIRA. > > On Fri, Sep 20, 2024, at 11:50 AM, Štefan Miklošovič wrote: >> 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 >
