Cassandra Admin study plan
Cassandra Admin · Give each week a clear focus.
8 weeks · About 6 hours per week
Cassandra Architecture and the Distributed Ring
Trace a single write from coordinator to commitlog, memtable, and flush, naming every in-memory and on-disk structure touched along the way
Diagram the ring with vnode token ranges and explain how gossip and the snitch spread topology and datacenter/rack information
Separate the roles of coordinator, replica, seed node, and client contact point, and predict what breaks when the only seed dies
Walk the read path through bloom filter, partition index, compression offset, chunk cache, and replica reconciliation, including read repair and digest mismatch
Your checkpoint
A 1,200-word write-path and read-path trace plus a labeled ring diagram, checked by a self-written 25-question quiz scored at 85% or higher.
Installation, Configuration, and Cluster Provisioning & Cassandra Architecture and the Distributed Ring
Install Cassandra from tarball and from the OS package on separate nodes and record where files, logs, and configs land in each case
Configure cassandra.yaml: cluster_name, seeds, listen_address, rpc_address, endpoint_snitch, num_tokens, and authenticator
Size the JVM heap for the node's RAM and set G1 flags and GC logging before first start
Bootstrap three nodes one at a time and confirm ownership and liveness with nodetool status, gossipinfo, and describecluster
Your checkpoint
A running three-node cluster plus a table of 12 settings changed from default, each with the old value, the new value, and the reason.
Data Distribution: Partitioning, Replication, Consistency, and Topology
Compute token ownership by hand for a single-token node and for 16 vnodes, then check the math against nodetool ring
Select replication factors per datacenter with NetworkTopologyStrategy and justify every number against failure and latency targets
Build a quorum table mapping ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM, ALL, and SERIAL to the number of replica failures each tolerates
Predict, then verify in the lab, what happens to reads and writes when one and then two replicas are stopped
Explain how hinted handoff and read repair mask short outages and where they stop helping
Your checkpoint
A consistency worksheet covering RF 3 and RF 5 across six consistency levels, with eight failure predictions that matched observed lab behavior.
Data Distribution: Partitioning, Replication, Consistency, and Topology & Performance Tuning: Compaction, Caching, Read/Write Path, and JVM
Verify quorum behavior from cqlsh using the CONSISTENCY command and query tracing while nodes are down
Compare STCS, LCS, TWCS, and UCS on write amplification, space amplification, and read cost, and match each to a table shape
Set compaction options per table and measure SSTable counts and p99 read latency before and after
Decide key cache versus row cache versus chunk cache for two contrasting tables and defend leaving row cache off
Your checkpoint
A lab report with before/after p99 read latency and SSTable counts for one compaction strategy change, plus a written cache decision for each table.
Performance Tuning: Compaction, Caching, Read/Write Path, and JVM
Instrument the read path using tracing and nodetool tablestats to count tombstones and bloom filter false positives per read
Tune the JVM: heap size, G1 pause target, GC logging, and read the resulting log for pause distribution and promotion failures
Adjust concurrent_reads, concurrent_writes, commitlog_sync, and memtable flush thresholds, stating the tradeoff behind each change
Diagnose a tombstone-heavy table and write the fix using TTL policy, compaction strategy, or a data model change
Explain how commitlog sync mode and unlogged batches affect write latency and durability
Your checkpoint
A tuning profile for one write-heavy and one read-heavy table listing every changed setting with its old value, plus a GC log summary showing max pause and heap occupancy.
Data Modeling and CQL Schema Design & Repair, Backup, Restore, and Anti-Entropy
Derive tables query-first from five access patterns, choosing partition and clustering keys for each query
Do partition-size math at projected row counts and rework keys so no partition exceeds 100 MB or roughly 100k rows
Weigh secondary indexes, materialized views, and denormalized duplicate tables, and write the decision rule you will apply
Take a snapshot and enable incremental backups for a keyspace, then restore one table with sstableloader and time it
Your checkpoint
A CQL schema for a five-query use case with partition-size estimates per table and a timed restore of one table from snapshot.
Repair, Backup, Restore, and Anti-Entropy & Security: Authentication, Authorization, Encryption, and Audit
Run a full repair and an incremental repair, read the merkle tree validation output, and set a repair schedule shorter than gc_grace_seconds
Explain how hinted handoff, read repair, and anti-entropy repair overlap and which failures each one cannot cover
Enable PasswordAuthenticator and CassandraAuthorizer, create roles, and grant least-privilege permissions on a keyspace
Enable client and internode TLS plus audit logging, then trigger a denied query and confirm the denial is logged
Your checkpoint
A secured cluster with TLS and audit logging, with captured audit lines for one successful and one denied query, plus a repair run log showing duration and validation outcome.
Operations, Monitoring, Troubleshooting, and Upgrades & Security: Authentication, Authorization, Encryption, and Audit
Build a monitoring checklist from nodetool tpstats, tablestats, netstats, and key JMX metrics, with alert thresholds for each
Rehearse a rolling upgrade and a node replacement using replace_address, listing the pre-checks before either
Triage three symptoms in the lab: dropped mutations, a large pending compaction backlog, and a node stuck bootstrapping
Audit the cluster against the security checklist: default credentials removed, remote JMX disabled, audit log retention set
Take a timed 60-question mock exam across all eight domains and review every missed question
Your checkpoint
A one-page incident triage runbook plus a timed mock exam scored at 80% or higher, with a written review of every missed question.
Milestones
Week 2: nodetool status shows UN for all three nodes, describecluster reports the expected snitch and schema agreement, and the 12-setting config table is complete.
Week 4: Quorum worksheet predictions were confirmed in the lab: with RF 3 and QUORUM, losing one replica still succeeds while losing two fails, shown through cqlsh tracing output.
Week 6: Schema review passes: every table's partition stays under 100 MB at projected row counts, and the timed restore of one table finishes in under 30 minutes.
Week 8: Mock exam scored at 80% or higher, and every weak area is written into a 30-day follow-up list with the domain number attached.