Upgrade Apache Cassandra

Master upgrading Apache Cassandra clusters with minimal downtime through practical, hands-on strategies, planning, testing, and safe execution for efficient, low-risk upgrades.

Acquire prerequisite knowledge on Apache Cassandra to effectively engage with this upgrade course. Expect experience installing, configuring, and administering Cassandra, and understanding how Cassandra manages large data sets.

Upgrading software replaces an older version with a newer one to gain improved performance, bug fixes, and updated security for databases and drivers.

Plan upgrade downtime to minimize impact. Upgrade one Cassandra node at a time for near zero downtime, test in staging, and validate backups, apps, and drivers for compatibility.

Upgrade Apache Cassandra using an in-place, rolling upgrade to update nodes one by one, minimizing downtime and avoiding new hardware while preserving data and cluster configuration.

Compare the open source community edition of Apache Cassandra with DataStax enterprise built on Cassandra, and learn upgrade guidance plus features like security analytics, search, and graph capabilities.

Learn how Apache Cassandra differentiates current from archived software, review the latest releases on the downloads page, and plan upgrades to supported 5.0 and 4.1/4.0 versions for production environments.

Explore the Cassandra upgrade path from 3.11 to 3.11.17, then to 4.0/4.1, and finally to 5.0, with guidance on not skipping intermediate releases.

Learn why downgrading the Cassandra version is discouraged and how it can lead to issues and data corruption.

Learn to manage server operating systems for Cassandra, compare Linux distributions such as Red Hat Enterprise Linux and Rocky Linux, and note subscription requirements and enterprise-level compatibility.

Learn how Apache Cassandra versions align with Python support, highlighting that most versions require Python 3 or above, with only a few older versions needing Python 2.

Discover how Apache Cassandra, written largely in Java, runs on Java 8 for 3.11, on Java 8 or 11 for 4.x, and on Java 11 or 17 for 5.x.

Compare JDK and JRE, and OpenJDK versus Oracle JDK, noting Cassandra needs JRE, not JDK; OpenJDK is free, while Oracle JDK is commercial.

On Rocky Linux 9.5, log in as root to install Java Runtime Environment version eight and OpenJDK version eight using dnf search and install; internet access is required.

Install OpenJDK 11 on a Rocky Linux 9.5 server using DNF, verify internet access, and switch the active Java version from 8 to 11 with update-alternatives.

Install and switch to OpenJDK 17 on a Rocky Linux 9.5 server using dnf and update-alternatives, ensuring active Java version becomes 17 and noting that the operation requires internet access.

Execute update-alternatives to switch Java versions as root, selecting Java 8, 11, or 17 as the active JRE, with a system-wide impact on all users and applications.

Upgrade Cassandra by selecting the new version for the current cluster, downloading and preparing configs, then upgrading nodes one by one with nodetool upgrade sstables, switching Java if required.

Explain how sstable versions and formats define on-disk data structure and compatibility in Cassandra. Show upgrading older sstables to the latest format with the node tool upgrade sstables.

Run nodetool upgradesstables on all cluster nodes after upgrading Apache Cassandra to update SSTable formats and prevent read/write inefficiencies and data inconsistencies.

Explore why Cassandra backups are critical during upgrades to safeguard against data loss, enable recovery in case of failures, and provide a fallback if upgrade encounters data corruption or incompatibility.

Contrast minor and major upgrades in Apache Cassandra, detailing bug fixes and performance gains within the same major version, versus major changes with new features and compatibility planning.

Stagger upgrades across data centers in a multi-dc Cassandra cluster to minimize downtime, validate each center, and maintain availability during the rollout, one data center at a time.

Maintain a mixed version cluster during a rolling upgrade through version compatibility, enabling data exchange and normal operation. Avoid schema changes, ensure upgrade paths, and test in staging before production.

Manage three Rocky Linux 9.5 servers to upgrade Apache Cassandra, performing one minor upgrade and two major upgrades using tarball versions.

Upgrade a three-node Cassandra 3.11.8 cluster to 3.11.17 using an in-place, minor version upgrade on Rocky Linux 9.5, Solid Cluster.

Review the Cassandra user's bash profile to configure environment variables for Cassandra home, config files, and logs, and add the Cassandra home bin folder to the path.

Gathering this basic information helps ensure a smooth upgrade process for Cassandra clusters. Upgrading from 3.11.8 to 3.11.17 is feasible for this cluster.

Download and extract cassandra 3.11.17 binaries, then copy them to all cluster nodes and extract on each node; configure with provided files and set permissions.

Compare cassandra.yaml across versions 3.11.8 and 3.11.7 using meld, and update the right-side file to match the left, covering cluster name, tokens, and new parameters like saved caches directory.

Compare cassandra-rackdc.properties across Cassandra versions 3.11.8 and 3.11.17, update the data center name on the right, and ignore new entries.

Compare the cassandra-env.sh file across Cassandra versions 3.11.8 and 3.11.17, identify four missing entries, and complete all changes to align the environment configuration.

Compare the jvm.options across Cassandra versions, update memory settings and the garbage collector log file on the right side, and complete all jvm.options changes.

Copy updated Cassandra configuration files to cluster nodes via secure copy and update rack dc properties file on each server, ensuring rack dc settings across versions 3.11.7, 3.11.8, and 3.17.8.

Review the Solid Cluster, a three-node Cassandra cluster in a single data center, currently on 3.11.8, and plan an in-place rolling upgrade to 3.11.17 with downloaded binaries and prepared configs.

Upgrade a three-node apache cassandra cluster from 3.11.8 to 3.11.17 by draining and stopping each node, updating configuration folders and binary links, and restarting all nodes until all run 3.11.17.

Execute nodetool upgradesstables on each node to upgrade ss tables from md format to new me format, while Cassandra performs compaction and completes the in-place upgrade from 3.11.8 to 3.11.17.

Remove the binaries and configuration files folders for version 3.11.8 across all Cassandra nodes after upgrading the cluster.

Upgrade the Cassandra cluster from 3.11.17 to 4.1.7 using an in-place major version upgrade. Do not skip 4.x releases before 5.0.

Review the Cassandra user’s bashprofile to verify Cassandra home, config, and log files environment variables and to add the Cassandra bin folder to the path.

Gather essential cluster information to facilitate a smooth upgrade from Cassandra 3.11.7 to 4.1.7, as outlined in the Cassandra 3.11.17 cluster summary.

Download and extract Cassandra 4.1.7 binaries via wget, then copy with scp to remaining cluster nodes and review the configuration files.

Compare Cassandra config changes across versions 3.11.17 and 4.1.7, update cassandra.yaml with renamed and new parameters, and align settings using a file-diff tool.

Compare Cassandra rack dc properties between 3.11.17 and 4.1.7, update the right side with the correct data center name, note new entries, ignore changes, and complete the adjustments.

We compare cassandra-env.sh between Cassandra versions 3.11.17 and 4.1.7, identify four missing entries, align the files so they contain the same entries, and complete the changes.

Configure JVM memory with Xms and Xmx (equal values) and enable GC logging via x log GC, using appropriate JVM server options for Cassandra versions 3.11.17 and 4.1.7.

Propagate Cassandra configuration version 4.1.7 across all nodes by securely copying files with scp, updating the rackdc.properties rack name, and verifying consistency with version 3.11.17.

Perform a rolling upgrade of a three-node cassandra cluster in a single data center from 3.11.17 to 4.1.7, after preparing binaries and configs, while maintaining uptime during the in-place upgrade.

Upgrade the Cassandra cluster to 4.1.7 by draining and stopping the first node, updating configuration and binary folders, switching soft links, and starting all three nodes.

Upgrade Cassandra from 3.11.17 to 4.1.7 using an in-place upgrade, upgrading sstables node by node with nodetool and letting compaction convert to the ENB format.

Upgrade the Cassandra cluster from Java 8 to Java 11, ensuring all nodes run Cassandra 4.1.7 on OpenJDK 11, by draining, stopping daemons, and switching Java versions.

Remove old Cassandra binaries and configuration folders for version 3.11.17 after upgrading the cluster, and apply the cleanup across all remaining nodes.

Upgrade a three-node Cassandra cluster from 4.1.7 to 5.0.2 using an in-place upgrade. Review covers home, binaries, config, data, logs, and the folder structure, including CDC files and commit logs.

Review the Cassandra user's bash_profile to verify Cassandra home, configuration, and log environment variables, and confirm Cassandra home bin is added to the system path.

Gather essential cluster information to ensure a smooth and efficient upgrade from Cassandra 4.1.7 to 5.0.2.

Download and extract Cassandra version 5.0.2 binaries, copy to cluster nodes via secure copy, and organize configuration files and permissions in the dedicated folders.

Compare cassandra.yaml across 4.1.7 and 5.0.2 and update the right-side file. Explore new 5.0 parameters like heap dump, incremental backups, snitch options, and storage attached indexes.

Compare the Cassandra rack dc properties file from versions 4.1.7 and 5.0.2, update the right-side file with the correct data center name, and confirm no other differences.

Compare the Cassandra env.sh files from version 4.1.7 and 5.0.2, note the missing entries, align both files, and implement all env.sh changes.

Configure Cassandra’s jvm options by setting xms and xmx to the same value to allocate heap memory, and enable the xlog gc log in java 11 and 17 server options.

Propagate version 5.0.2 Cassandra configurations across a multi-node cluster by securely copying updated files and updating the rack name in the rack dc properties on each node.

Learn how to perform a rolling upgrade of an Apache Cassandra cluster from 4.1.7 to 5.0.2, including preparing binaries and configs and upgrading nodes one by one.

Upgrade the Cassandra cluster to 5.0.2 by draining, stopping, then starting each node, updating configuration folders and binary links on all three Metal Gear servers.

Run nodetool upgradesstables on each node, upgrading all SS tables to the new NB format one node at a time, with compaction handling the upgrade to 5.0.2.

Upgrade Cassandra from Java 11 to Java 17 on Cassandra 5.0.2 using OpenJDK 17, update alternatives, drain and stop daemon, then restart the cluster.

Enable new features in cassandra 5.0 by enabling tri indexed sstables and mem tables, and adopting the unified compaction strategy, dynamic data masking, and storage attached index.

Remove old Cassandra version 4.1.7 binaries and configuration folders after upgrading the cluster. Apply the same cleanup to all remaining nodes to complete the upgrade process.