Thanks for looking into this.
Jira ticket CASSANDRA-19948
<https://issues.apache.org/jira/browse/CASSANDRA-19948> has been created
for this.
On 23/09/2024 16:59, Josh McKenzie wrote:
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
