Apache Cassandra Changelog #9

We are pleased to announce that the latest release of Apache Cassandra is 4.0 GA (pgp, sha256, and sha512). Please read the release notes and let us know if you encounter any problems.

Note: As the docs are not yet updated, the bintray location for Debian users is replaced with the ASF’s JFrog Artifactory location.

This release is the cumulation of six years of work that sets a baseline for future releases. Read the announcement blog for more details.

We can also confirm the release of both Apache Cassandra 3.0.25 (pgp, sha256, and sha512) and Apache Cassandra 3.0.11 (pgp, sha256, and sha512) on 28 July. Please read the 3.0.25 release notes here and the release notes for 3.0.11 here.

Downloads of source and binary distributions for the latest stable and older supported versions are listed in our download section.

Stefan Miklosovic highlighted an issue with the obfuscation of passwords in Apache Cassandra’s native audit logging. This has been fixed for Apache Cassandra 4.0 to enable organizations in highly audited industries to use the GA release.

We are advising users of Apache Cassandra 3.0.23, 3.0.24, 3.11.9, and 3.11.10 to upgrade as soon as possible. An issue that creates the potential for data corruption during schema changes has been found, the full details are here. Thanks go to Jordan West for reporting the bug!

Join the Cassandra mailing list to stay updated

We are pleased to announce that Jon Meredith has been invited by the Project Management Committee (PMC) to become a committer, and he has accepted! Congratulations to Jon, and thank you for all your contributions. 👏

With the release of Apache Cassandra 4.0, we have established a issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484.[New Release tracking Kanboard,window=_blank]. For those just getting started with the project, there is a "https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160[Starter Tickets,window=_blank]" quick label that corresponds to our Low Hanging Fruit status. Any of these tickets should be of appropriate complexity for someone new to the project to take on.

For those new to the project, we’ve adopted a similar process for major features to some other Apache projects in the form of CEPs or Cassandra Enhancement Proposals. CEPs are now a required step for important changes to the Cassandra code base and with the release of 4.0, we’re seeing more features being proposed. Congratulations to Maulin VasavadaI for passing the vote for CEP-9 on making SSLContext creation pluggable.

CEP-10 has also been voted on and has received approval from the community to continue. This CEP is a proposal for a mechanism to evaluate whole clusters, or individual classes, with a deterministically pseudorandom ordering of all thread and message events. The goal will be to simulate a cluster and actions on it (or simpler unit tests) so that the behavior is deterministic, repeatable, but pseudo-random.

CEP-11 is a proposal for using custom memtable implementations to support development and testing of improved alternatives. This proposal also enables a broader definition of "memtable" to better support more advanced use cases, such as persistent memory. So far, there has been some discussion about the architectural proximity of the memtable and commitlog implementation, and more input is always welcome!

The Cassandra community recently updated its website and has added several new entries to the Ecosystem page.

The Kubernetes SIG held an update on 1 July with the latest on K8ssandra and the CassKop operator (see video, below).

Jeff DiNoto gave an overview of K8ssandra’s progress. The project is seeking to hit a monthly cadence for point releases, and the big recent news is that 1.3 was released on 29 July. This version supports Apache Cassandra 4.0 and benefits from the stability and great new capabilities 4.0 offers, such as Virtual Tables, which is especially promising for Kubernetes. Other 1.3 features include pod scheduling enhancements, support for private container registries, backup and restore support for Azure blob storage. For a full breakdown of the new 1.3 features, read Jeff Carpenter’s release announcement.

Two major features for K8ssandra are in development for release at KubeCon North America: Remote restore and multi-cluster Kubernetes deployment support.

Jeff also explained that K8ssandra is being refactored, as part of the roadmap to 2.0, to provide a higher-level K8ssandra operator designed to be layered on top of a simple Helm install experience and provide greater control over cass-operator, Medusa, Reaper, and K8ssandra itself. The initial design of this document is available here.

Refactoring and API upgrade work also continues on the cass-operator, while Franck Dehay also detailed the upgrade of CassKop to version 2.0. The main feature of v2.0 is support for Cassandra 4.0.

CassKop 2.0 uses cass-config builder easing users from configuring Cassandra to K8ssandra by using the configuration changes in the CRD. Using cass-config also means CassKop supports Apache Cassandra 3.0 and 4.0 more easily.

<iframe width="560" height="315" src=https://www.youtube.com/watch?v=DjBrKPnu31E" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

“Maybe one of the most interesting features of Cassandra for us is that as our business continues to grow, and the number of nodes under management increases, we will naturally add more nodes to our own cluster to keep the processing capabilities the same.” - Instaclustr

“Like any supply chain network, our infrastructure involved a plethora of event sources with all different types of data contributing to net change to inventory positions, so we leveraged Kafka Streams to house the data and a Kafka connector to take the data and ingest it into Apache Cassandra and other data stores.” - Suman Pattnaik

Do you have a Cassandra case study to share? Email cassandra@constantia.io.