[ https://issues.apache.org/jira/browse/CASSANDRA-19948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885495#comment-17885495 ]
Josh McKenzie commented on CASSANDRA-19948: ------------------------------------------- >As long as the CQL client sees a write is successful, the CDC consumer will >definitely see that write too. Will it? I don't think this is true: * Given nodes A, B, C * CDC enabled on B and C (QUORUM) * Write hits node A and B, fails on C (CL=QUORUM success) * Ack to client that write is successful * B dies Now you have data on node A that is not available to CDC with a write at QUORUM that matched your CL request. Anti-entropy efforts _should_ resolve this, but there's no guarantees here. Or put more formally: if you non-equal sets of overlapping quorums, loss of the overlapping members leaves you with inconsistent views of the data between the quorums. The original requirements I was working with on CDC were "at least once delivery, period, full-stop". Which necessitates both a: using the same file for CDC log as WAL log (split f-sync == nightmare fuel for CDC reconciliation), and b: having your # CDC logs == your # replicas so you never have a replica write that doesn't make it to a CDC log. > 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