Apache Cassandra 5.0 Baseline, Java Requirements, Configuration Layout, and Release Awareness

Learning outcomes

Two AtlasMart developers both say “I tested Cassandra 5,” but one used a moving container tag and another used an old tarball with a different Java runtime and configuration tree. Their commands produce different behavior. Before deeper labs, the course needs an explicit version-and-configuration provenance record so a failure can be attributed to workload semantics rather than an unknown environment.

1. A reproducible baseline has more than one version number

5.0.9 identifies the Cassandra server release pinned for this chapter. It does not identify the Java patch, cqlsh Python environment, nodetool client runtime, a language driver, the container base distribution, or your host operating system. Reproducibility requires recording all components that can affect behavior.

Official Cassandra 5.0 Java documentation distinguishes build and runtime compatibility. Do not copy a blanket “Cassandra 5 requires Java 17” statement into every environment. Package maintainers and container images may supply a supported runtime independently of the host. The safe method is to follow the installation path's current documentation and record java -version in the same runtime context that launches Cassandra.

2. Configuration provenance: know which file the process used

The main server configuration is cassandra.yaml. Package/container installations commonly expose configuration under /etc/cassandra; tarball installations use the distribution's conf directory. The same logical setting can also be influenced by packaging entrypoints or environment-variable translation. Therefore “I edited a cassandra.yaml somewhere on disk” is not evidence that the running process consumed it.

Chapter 01 records, but does not tune, the surfaces that later chapters depend on: cluster_name; listen/broadcast/native transport addresses; seed configuration; endpoint snitch/locator/topology; data directories; commit-log directory; saved-cache directory; native transport port; authenticator; authorizer; client encryption; internode encryption; JMX access; and JVM options.

docker exec atlasmart-cass-1 sh -lc 'echo CASSANDRA_CONF=$CASSANDRA_CONF; ls -la "$CASSANDRA_CONF"'docker exec atlasmart-cass-1 sh -lc 'grep -nE "^(cluster_name|listen_address|rpc_address|broadcast_address|broadcast_rpc_address|endpoint_snitch|authenticator|authorizer|native_transport_port|commitlog_directory|saved_caches_directory):" "$CASSANDRA_CONF/cassandra.yaml"'docker exec atlasmart-cass-1 sh -lc 'grep -n "^data_file_directories:" "$CASSANDRA_CONF/cassandra.yaml"'docker exec atlasmart-cass-1 sh -lc 'cat "$CASSANDRA_CONF/cassandra-rackdc.properties"' 

Some values can be commented/defaulted, rewritten by the Docker entrypoint, or represented in separate files. Record the exact file path and final effective evidence. Later lessons should never assume an old default simply because it appeared in an earlier Cassandra release.

3. Storage paths and process identity are operational state

Cassandra's storage engine separates concerns that must not be collapsed into “the database folder.” Data directories hold immutable SSTable components and related table data. The commit log is an append-oriented durability mechanism for writes before they are safely represented in SSTables. Saved caches persist selected cache metadata/state according to configuration. These surfaces have different I/O patterns, capacity risks, backup semantics, and recovery roles.

In the Docker Official Image, mounting a named volume at /var/lib/cassandra makes course data survive container replacement. Running without a volume can be acceptable for a disposable demonstration, but it is misleading if the learner expects container replacement to preserve state. Persistence inside one Docker volume is still not a backup.

docker inspect atlasmart-cass-1 --format '{{json .Mounts}}'docker exec atlasmart-cass-1 sh -lc 'du -sh /var/lib/cassandra 2>/dev/null; find /var/lib/cassandra -maxdepth 2 -type d | sort | head -40'docker exec atlasmart-cass-1 sh -lc 'ss -lnt 2>/dev/null | grep -E ":(7000|7001|7199|9042)\b" || true' 

Port 9042 is the standard CQL native transport port. JMX is a separate management surface used by nodetool; the course deliberately keeps it inside the isolated container/network instead of publishing it broadly. TLS and authentication are also separate controls: enabling credentials does not automatically encrypt client traffic, and encrypting transport does not define authorization.

4. Release awareness: Cassandra 5.0 is a series, not a static sentence

Cassandra 5.0 introduced or advanced several capabilities that later chapters will use, including Storage-Attached Indexing (SAI), vector types/search, new storage-engine structures, guardrails, and operational improvements. Those names are not permission to copy commands from a random blog. Feature syntax, defaults, recommended compaction behavior, driver support, security advisories, and upgrade compatibility are version-sensitive.

One important example is compaction guidance. The course later teaches STCS, LCS, TWCS and UCS because operators need to understand their workload tradeoffs, but current 5.0 guidance recommends UnifiedCompactionStrategy for most new workloads. Chapter 01 therefore records the configured strategy without tuning it. Chapter 12 will measure and compare strategies against the then-current documentation rather than turning an older default into folklore.

5. Build an environment manifest and detect a bad baseline

docker network create atlasmart-cassandradocker volume create atlasmart-cass-1-datadocker run -d --name atlasmart-cass-1 --hostname atlasmart-cass-1 --network atlasmart-cassandra -e CASSANDRA_CLUSTER_NAME=atlasmart-course -e CASSANDRA_DC=dc1 -e CASSANDRA_RACK=rack1 -e CASSANDRA_ENDPOINT_SNITCH=GossipingPropertyFileSnitch -v atlasmart-cass-1-data:/var/lib/cassandra cassandra:5.0.9# After cqlsh is ready:docker exec atlasmart-cass-1 cassandra -vdocker exec atlasmart-cass-1 java -versiondocker exec atlasmart-cass-1 cqlsh -e "SHOW VERSION"docker exec atlasmart-cass-1 nodetool versiondocker exec atlasmart-cass-1 nodetool infodocker exec atlasmart-cass-1 cqlsh -e "SELECT cluster_name, release_version, cql_version, data_center, rack, partitioner FROM system.local;"docker inspect atlasmart-cass-1 --format '{{.Config.Image}} {{.Image}}' 

Deliberately wrong baseline

Replace the pinned image with cassandra:latest in a scratch command and you have created an environment whose future identity is unknown. Another failure is to point a node at a reused production seed/cluster name, potentially confusing discovery expectations. The correction is to delete only the disposable container, restore the course-specific cluster/network/volume names, and prove the resulting identity with both system tables and nodetool.

A Java mismatch on tarball/package paths should be diagnosed from the Cassandra startup log and java -version, not “fixed” by randomly changing JVM flags. Follow the current version's support matrix and package documentation; keep host Java and container Java conceptually separate.

Cleanup

docker rm -f atlasmart-cass-1docker volume rm atlasmart-cass-1-datadocker network rm atlasmart-cassandra

Production judgment

A version manifest is part of incident response and rollback design. A production upgrade plan needs the exact current/target server versions, Java compatibility, driver/native-protocol compatibility, topology, schema state, security advisories, backup/restore evidence, and rollback boundary. “5.0” alone is not sufficient to reproduce or defend an incident.

The next lesson uses this manifest to build the single-node lab carefully, inspect native/JMX/configuration evidence, and distinguish a startup race from a genuine connection failure.

Summary and next step

This lesson’s concepts, evidence path, failure boundaries, and production judgment should now be explicit enough to verify rather than assume. Re-run the check-your-understanding prompts and preserve any lab evidence you need before changing or cleaning up the environment.

Next, continue to Start a Single-Node or Container Lab, Connect with cqlsh, and Inspect Cluster Metadata.

Authoritative references

• Apache Cassandra 5.0 documentation — Current official documentation entry point for the 5.0 line.
• Apache Cassandra downloads — Official release page used to verify the current 5.0 patch.
• Cassandra architecture overview — Official architecture and wide-column/distributed design framing.
• Cassandra quickstart — Official Docker-oriented learning workflow and isolated-network approach.
• Cassandra configuration reference — Official cassandra.yaml semantics, including native transport and security-related settings.
• CQL querying and cqlsh — Official CQL/cqlsh connection and system.local examples.
• Java support for Cassandra 5.0 — Official Java build/runtime compatibility notes for Cassandra 5.0.
• Docker Official Image: Cassandra — Container-image usage and tag information for the Docker Official Image.