Cassandra 4.0 alpha1 makes repair behavior explicit

Repair status is useful only if it means the same thing on every replica. Cassandra 4.0's first alpha includes a change to incremental repair intended to correct inconsistent repaired data between nodes. The change affects when Cassandra separates data for repair, and it also changes what a full repair records afterward. That is a substantial operational difference inside a release whose most visible label is simply alpha1.

The release metadata records 8 September 2019 for 4.0-alpha1. The notes at that exact tag are the useful starting point for understanding its behavior. An alpha provides a concrete implementation to evaluate. It does not turn experimental options into established production choices, and the notes explicitly retain that distinction for several additions.

I find Cassandra's active-active design attractive when the application needs it. The first alpha interests me because it exposes the maintenance and compatibility obligations behind that design. A major release changes more than the commands an application sends during normal operation.

Incremental repair changes its sequence

The upgrade notes identify an incremental-repair problem that caused repaired data to become inconsistent between nodes. Their correction moves anticompaction to the beginning of incremental repair. In the previous behavior described by the notes, anticompaction ran at the end. Changing that sequence changes when Cassandra establishes the data groups involved in the operation.

Full repairs also change behavior. They no longer mark data as repaired. This matters for automation that treats a full repair as an operation that both reconciles data and changes its repaired classification. The notes state those effects separately, so a process that depends on the classification has to account for the new semantics.

For installations that used incremental repair before upgrading, the notes recommend a full repair after the upgrade to resolve possible inconsistencies. That instruction has a specific historical reason. It addresses data produced under the earlier behavior. It should not be generalized into a claim that any successful upgrade automatically establishes consistent repaired state.

The same alpha exposes repair operations that answer different questions. nodetool repair --preview estimates the streaming expected for a repair. nodetool repair --validate checks consistency of repaired data between nodes. These are useful because an operator may need information about the proposed work or the existing repaired state without treating every invocation as the same repair operation.

Query recording supports a different kind of inspection

The alpha's full query log records incoming queries, their approximate invocation time, bind parameters and query options. The notes describe a binary log based on Chronicle Queue, with limits on heap and disk use. Commands can enable, disable or reset it, while fqltool can dump or tail a human-readable representation.

Those recorded parameters distinguish the log from a list of statement templates. A prepared query's text alone omits the values that select a partition or set a column. Query options also affect the request the server executes. Recording them gives an evaluator more of the original request context.

Audit logging is a separate addition in the notes. It covers incoming CQL requests and authentication attempts, including unsuccessful logins. Query reconstruction and access auditing overlap in the activity they observe, but they answer different operational questions. The presence of both deserves more precise language than saying the release adds logging.

I value the ability to inspect database behavior without relying entirely on application recollection. That is a judgement about the usefulness of the recorded information, not a claim that recording requests proves their results correct. Repair validation and query logs provide evidence about different parts of a system.

Compatibility decisions are part of the alpha

The versioned notes remove support for Thrift and COMPACT STORAGE tables in 4.0. Compact tables must first migrate through the supported statement on the older release line. Cassandra 4.0 will refuse startup when table flags still indicate a non-CQL table. This makes schema compatibility a prerequisite to starting the new process.

Storage compatibility also imposes a sequence. The alpha removes support for pre-3.0 SSTable formats, so an installation cannot move directly from a 2.x version to 4.0. The notes require passing through a suitable 3.0 or 3.x version and upgrading SSTables there. Updating the executable does not transform every historical file that remains on disk.

Legacy authentication tables have their own prerequisite. The notes remove the migration code and require migration and removal of the old tables before upgrading. This is another case where an installation's history matters. Two clusters running the same current version can still differ in the old structures they retain.

Background repair options also disappear. The table properties read_repair_chance and dclocal_read_repair_chance are removed and rejected. An old schema-management script can therefore contain settings that the new release no longer accepts. That consequence follows from the schema interface, independently of whether the application changes its ordinary query text.

Experimental additions retain narrower audiences

Transient replication and cheap quorums are explicitly experimental in the alpha notes. Their intended audience consists of expert users prepared to validate the database for their applications and deployment practices. The release should not be described as making those options routine simply because it contains their implementation.

Java 11 support carries an experimental designation too. The JVM options split into version-specific files where appropriate, and the notes distinguish development compilation from release-build requirements. Runtime compatibility and build requirements are related, but neither is established by the presence of a new Java version in a feature list alone.

The alpha also contains less speculative changes, including whole-SSTable streaming and startup connection checks. These make useful evaluation subjects alongside repair behavior. Their inclusion does not remove the need to distinguish each feature's status from the status of the release as a whole.

Cassandra 4.0-alpha1 gives evaluators a versioned set of these contracts. A repair process must account for the changed meaning of full and incremental repair, while an upgrade process must account for the schema and file formats it brings forward. The exact-tag notes preserve those requirements together, including prerequisites that have to be completed before the new server can start.