Why architecture matters here

Ops failures cascade to data loss. Architecture matters because rolling + repair + capacity + upgrade all need runbooks.

Advertisement

The architecture: every piece explained

The top strip is lifecycle. Rolling restart. Node replace. Bootstrap new node. Repair schedule.

The middle row is tuning. Capacity planning. GC + JVM tuning. Compaction strategy. Observability.

The lower rows are safety. Backup + restore. Upgrade path. Ops — SLO + runbook + drills.

Cassandra ops — rolling restart + node replace + capacity + observability + tuningkeep the cluster healthy in productionRolling restartone node at a timeNode replacesame IP + streamingBootstrap new nodejoin + streamRepair schedulereaper + subrangeCapacity planninggrowth + headroomGC + JVM tuningG1 / ZGCCompaction strategySTCS/LCS/TWCSObservabilitynodetool + JMX + metricsBackup + restoresnapshotsUpgrade pathversion-by-versionOps — SLO + runbook + drillsplantunechoosewatchprotectupgradeupgradeoperateoperate
Cassandra operations at a glance.
Advertisement

End-to-end flow

End-to-end: rolling restart runs one node at a time; repair Reaper follows nightly. Capacity dashboards show 30% headroom. GC pauses in ZGC below 10ms. Snapshots weekly. Upgrade rehearsed on staging. Runbooks in git.