What you will learn
You will connect node identity, datacenter placement, seeds, and keyspace replication. This example uses Cassandra 4.1 on Linux; package names and Java requirements must match the exact release you install.
Before you begin
Prepare three isolated Linux hosts named host1.sample.com, host2.sample.com, and host3.sample.com with synchronized clocks, persistent data disks, and the same approved Cassandra/JVM versions. Provision TLS and credentials for any network-accessible installation. Do not expose native transport or JMX to the public internet.
1. Check the hosts
java -version
free -h
df -h
timedatectl
ulimit -n
Compare the results across nodes. Time synchronization matters; using the same display timezone does not synchronize clocks. Size JVM heap and OS limits from the release guidance and workload rather than copying a production host’s values.
2. Give each node a stable identity
In cassandra.yaml, use the same cluster name and seed list, but a distinct listen and RPC/broadcast address for each host. Use GossipingPropertyFileSnitch and define placement in cassandra-rackdc.properties.
dc=dc1
rack=rack1
Use host1.sample.com and host2.sample.com as the example seeds and give each of the three hosts its own resolved listen address. Use different rack labels where failure domains actually differ. Seed nodes provide discovery; they are not primary nodes and do not hold all data.
3. Start and inspect membership
Start the configured Cassandra service on the first seed, then bring up the other nodes one at a time. Wait for each node to become normal before continuing. Inspect the service log if a node cannot join.
nodetool status
nodetool describecluster
nodetool netstats
The expected starting state is every intended node Up/Normal (UN), one schema version, and no unfinished topology operation. A joining or leaving node is a reason to investigate before starting another change. Also record read/write latency and disk headroom; ring membership alone does not demonstrate application health.
4. Create and query a replicated table
CREATE KEYSPACE tutorial WITH replication = {'class':'NetworkTopologyStrategy','dc1':3};
CREATE TABLE tutorial.events (tenant_id text, event_id int, message text, PRIMARY KEY (tenant_id, event_id));
CONSISTENCY LOCAL_QUORUM;
INSERT INTO tutorial.events (tenant_id,event_id,message) VALUES ('demo',1,'cluster ready');
SELECT * FROM tutorial.events WHERE tenant_id='demo';
Connect through another node and repeat the partition-key query. The key selects a partition; it is not a full-cluster table scan.
Example output
The following is an illustrative, normalized lab result, not output captured from a live customer system. Your versions, addresses, timings, and row counts will differ.
tenant_id | event_id | message
-----------+----------+---------------
demo | 1 | cluster ready
(1 rows)
This is the expected shape of the SELECT result after the sample INSERT. Read the same partition through another contact point before calling the cluster ready.
Verify the result
The ring contains exactly three intended nodes and the row is readable through every contact point. Record the schema and the driver’s local datacenter setting. In a lab, stop only one node and repeat the quorum read; two replicas should remain available.
Troubleshooting
A cluster-name mismatch prevents joining. Incorrect broadcast addresses can make an apparently running node unreachable to peers. Authentication or TLS failures require matching client/server configuration; do not resolve them by removing security settings.
Recovery and next steps
If startup fails, stop the new node and correct configuration before retrying. Preserve logs and data. A node that has joined an existing ring must be removed through a topology procedure rather than by deleting its directories.