18.10.2026 Problem:
A client planned a rolling patch upgrade of a 5-node Apache Cassandra 4.1.x cluster running on cloud VMs, combined with a minor RHEL 9.x OS update. They submitted their runbook for review and asked whether the OS update affected JVM and Python support, whether there were known compatibility issues, and whether the plan carried any risks.
Process:
Step 1: Review the runbook
We reviewed the client’s procedure: pre-upgrade config backups and snapshots, a per-node drain/stop/replace/start cycle, a manual config merge, repair, health checks, and a final sstable upgrade.
Step 2: Check the target version
A newer patch release was available in the 4.1 line, so we recommended targeting the latest patch instead of the version originally planned.
Step 3: Assess compatibility
We found no reported breaking changes between the current and target Cassandra patch versions, and no known issues with the RHEL 9.x minor update.
Step 4: Correct the upgrade order
The plan upgraded non-seed nodes first and seed nodes last, which is the opposite of the official guidance. We recommended starting with the seed node.
Step 5: Simplify config handling
Because this was a patch upgrade with no config changes, a line-by-line merge was unnecessary. We advised keeping a copy of the new default configs for reference and reusing the existing config set as is.
Step 6: Refine post-upgrade maintenance
We clarified that the sstable upgrade is optional for a patch release but recommended running it node by node once the whole cluster is upgraded. We also advised running routine repair after the upgrade on one node at a time.
Step 7: Validate the revised plan
The client updated the runbook with these recommendations and added a rollback procedure. We reviewed the revised version and confirmed it.
Solution:
The client received a validated runbook covering: an upgrade to the latest 4.1.x patch, a seed-first rolling order with health verification before each next node, reuse of the existing configuration, sequential repair after the upgrade, a node-by-node sstable upgrade once the cluster is stable, and a rollback path.
Conclusion:
The review fixed the node order, removed an unnecessary and error-prone config merge, and enforced sequential maintenance operations. The client now has a lower-risk, confirmed upgrade plan, and standby support was offered for the implementation window.