Cluster topology places ScyllaDB nodes into datacenters and racks or zones so replicas and quorum can survive infrastructure failures. A production cluster uses multiple servers rather than several Docker containers on one machine. section 9.2 section 9.2.1
Topology and replication are designed together. Replication factors are set per datacenter, allowing a standby site for major incidents, a smaller analytics site, or a regional site for globally distributed traffic. ScyllaDB replicates across datacenters and accounts for them when calculating quorums. section 9.2.1
A practical starting layout is:
- Use a replication factor of 3. section 9.2.1
- Spread nodes across at least three zones or racks to tolerate loss of an entire rack while preserving quorum consistency. section 9.2.1
- Choose the snitch before building the cluster, because changing it requires taking the cluster offline. section 9.1.6
- Prefer a cloud-provider snitch when supported, or GossipingPropertyFileSnitch when explicit datacenter and rack names are needed. section 9.1.6
Explicit rack and datacenter placement
With GossipingPropertyFileSnitch, each node defines its own location in cassandra-rackdc.properties. A node assigned dc=datacenter1 and rack=rack1 becomes part of that declared failure-domain layout. This gives direct control over names, but requires manual setup on every node. section 9.1.6
Seeds help a newly joining node discover this layout. On startup, a new node contacts an existing seed to learn other node addresses and positions on the hash ring; after joining, normal gossip distributes that information. Seeds do not determine where nodes should be placed. section 9.1.2
Topology is also an incident-prevention decision. If enough nodes are offline that a chosen consistency level cannot be met, requests fail. Restoring nodes is the immediate remedy; spreading nodes more safely and operating on one node at a time reduce the risk of quorum loss. section 11.3.3
Figure 9.4 By running your Scylla cluster across multiple racks, you can tolerate the loss of an entire rack and still preserve quorum consistency.
This layout illustrates why rack separation matters: losing one rack can still leave enough replicas available for quorum consistency. section 9.2.1
