Cassandra alpha3 tightens repair diagnostics and request deadlines
Cassandra 4.0-alpha3 improves the interpretation of repaired data and changes how replicas account for request time. Both changes expose assumptions behind distributed correctness.
A consistency diagnostic needs to distinguish corruption from differences the storage engine can legitimately produce. Cassandra 4.0-alpha3 makes that distinction more precise by excluding purgeable tombstones and legacy counter shards from repaired-data tracking. These are small entries in a release whose broader purpose is to make the next major version testable. They concern an important operational question, however. When two replicas disagree, does the disagreement establish that something is wrong?
The Apache release record dates alpha3 to February 6, 2020. The tagged changelog identifies the repaired-data changes as CASSANDRA-15462 and CASSANDRA-15461. It also records a new default for cross-node timeout accounting. Together these changes make the alpha interesting as a study of the conditions under which Cassandra can draw conclusions about distributed state.
I find Cassandra compelling for systems that actually need active-active operation at scale. That interest makes the interpretation of replica state especially important to me. An application chooses Cassandra for a difficult distribution problem, and the tools used to inspect that distribution need to describe their own uncertainty accurately.
What a repaired-data mismatch means
The configuration shipped with alpha3 describes tracking the repaired state of data during reads and comparing that state between replicas. It distinguishes confirmed mismatches from unconfirmed ones. Pending repair sessions, unrepaired partition tombstones and other conditions can prevent a disparity from establishing a conclusive inconsistency. A confirmed mismatch warrants investigation because it may indicate corruption or data loss.
That qualification matters when interpreting a metric. A counter that rises whenever two internal representations differ would conflate an operational finding with an implementation detail. Excluding purgeable tombstones from the comparison narrows what the diagnostic treats as meaningful. The corresponding exclusion of legacy counter shards makes the same general point. A comparison must account for the kinds of state the database stores, including state whose continued presence is not itself proof of a logical disagreement.
Alpha3 exposes separate switches for range reads and single-partition reads. Its configuration explains that partition-read tracking only occurs above consistency level one and when a digest mismatch occurs. Range queries do not currently use digests, so enabling their tracking includes it in all range reads. That difference gives the two switches distinct cost implications. A setting that adds occasional diagnostic work to one query path may add work throughout another.
The shipped defaults leave both forms of tracking disabled. An explicit configuration for enabling partition-read tracking while leaving range tracking off is therefore easy to state without implying that the release enables either automatically.
repaired_data_tracking_for_range_reads_enabled: false
repaired_data_tracking_for_partition_reads_enabled: true
report_unconfirmed_repaired_data_mismatches: false
The final setting controls a separate metric for unconfirmed mismatches. The configuration comments explain that these reports are less actionable and can create a signal-to-noise problem. Keeping the distinction visible is useful even when investigating a fault. Evidence that two replicas differ and evidence that repaired data is inconsistent support different conclusions.
Time already spent still counts
CASSANDRA-15216 changes cross_node_timeout to true by default. The same tagged configuration explains the behaviour. With cross-node timeout accounting disabled, a replica assumes that the coordinator forwarded a request instantly. Under overload, that assumption allows the replica to spend additional time processing work whose coordinator has already timed out.
Enabling the setting makes the request account for time spent before the replica receives it. The request deadline therefore has meaning across a forwarding boundary. This is especially relevant to overload because processing expired work consumes capacity while the system is already struggling to meet deadlines. The change addresses how Cassandra allocates that capacity, without claiming that a different timeout default increases the capacity itself.
The release notes attach an explicit clock assumption. Operators must keep clocks mostly synchronised, and the project observes that last-write-wins correctness already requires this. Timeout accounting makes that dependency relevant to another part of execution. It would be misleading to describe the new default as a deadline mechanism independent of the machines on which it runs.
I prefer this treatment of the assumption because it places a distributed behaviour next to the condition it needs. Cassandra already asks an operator to understand replication. Its timeout configuration should make the related timing model equally available for inspection.
An alpha also documents the upgrade boundary
The alpha3 upgrade notes describe changes that extend beyond this particular preview. They warn that queries against certain system tables can fail during a mixed-version upgrade because 4.0 adds columns to those tables. The notes name query tracing as an affected path and identify 3.0.20 and 3.11.6 as versions that pre-add the columns.
That is a concrete reason to read the upgrade material alongside the list of fixes. Ordinary application requests are not the only requests a mixed-version cluster executes. A driver tracing a query can reach system tables whose definitions are changing underneath the upgrade. Compatibility work therefore includes administrative and diagnostic activity, even when the application schema stays the same.
The same notes label Java 11 support experimental and describe distinct JVM option files for Java 8 and Java 11. Alpha3 is a preview of work still being evaluated. Its useful contribution today is a more specific description of what the database compares, which timing assumptions it applies, and which compatibility boundaries its operators must understand.