Switching snitches
Because snitches determine how the database distributes replicas, the procedure to switch snitches depends on whether the topology of the cluster changes:
-
If data has not been inserted into the cluster, there is no change in the network topology. This means that you only need to set the snitch; no other steps are necessary.
-
If data has been inserted into the cluster, it’s possible that the topology has changed and you need to perform additional steps.
A change in topology means that there is a change in the datacenters and/or racks where the nodes are placed. Topology changes may occur when the replicas are placed in different places by the new snitch. Specifically, the replication strategy places the replicas based on the information provided by the new snitch. The following examples demonstrate the differences:
-
No topology change
Change from five nodes using the
DseSimpleSnitch
(default) in a single datacenter.To five nodes in one datacenter and 1 rack using a network snitch such as the
GossipingPropertyFileSnitch
. -
Topology changes
-
Change from 5 nodes using the
DseSimpleSnitch
(default) in a single datacenterTo 5 nodes in 2 datacenters using the
GossipingPropertyFileSnitch
(add a datacenter).If splitting one datacenter into two, create a new datacenter with new nodes. Alter the keyspace replication settings for the keyspace that originally existed to reflect that two datacenters now exist. Once data is replicated to the new datacenter, remove the number of nodes from the original datacenter that have "moved" to the new datacenter.
-
Change from 5 nodes using the
DseSimpleSnitch
(default) in a single datacenterTo 5 nodes in 1 datacenter and 2 racks using the
GossipingPropertyFileSnitch
(add rack information).
-
Where is the cassandra.yaml
file?
The location of the cassandra.yaml
file depends on the type of installation:
Installation Type | Location |
---|---|
Package installations + Installer-Services installations |
|
Tarball installations + Installer-No Services installations |
|
Where is the cassandra-topology.properties
file?
The location of the cassandra-topology.properties
file depends on the type of installation:
Installation Type | Location |
---|---|
Package installations + Installer-Services installations |
|
Tarball installations + Installer-No Services installations |
|
Where is the cassandra-rackdc.properties
file?
The location of the cassandra-rackdc.properties
depends on the type of installation:
Installation Type | Location |
---|---|
Package installations + Installer-Services installations |
|
Tarball installations + Installer-No Services |
|
Procedure
-
Create a properties file with datacenter and rack information.
-
cassandra-rackdc.properties
GossipingPropertyFileSnitch
,Ec2Snitch
, andEc2MultiRegionSnitch
only. -
cassandra-topology.properties
All other network snitches.
-
-
Copy the
cassandra-rackdc.properties
orcassandra-topology.properties
file to the configuration directory on all the cluster’s nodes. They won’t be used until the new snitch is enabled. -
Change the snitch for each node in the cluster in the node’s
cassandra.yaml
file. For example:endpoint_snitch: GossipingPropertyFileSnitch
-
If the topology has not changed, you can restart each node one at a time.
Any change in the
cassandra.yaml
file requires a node restart. -
If the topology of the network has changed, but no datacenters are added:
-
Shut down all the nodes, then restart them.
-
Run a
sequential repair
andnodetool cleanup
on each node.Failure to run
nodetool cleanup
after adding a node may result in data inconsistencies including resurrection of previously deleted data.
-
-
If the topology of the network has changed and a datacenter is added:
-
Replicate data into new datacenter. Remove nodes from old datacenter.
-
Run a
sequential repair
andnodetool cleanup
on each node.Failure to run nodetool cleanup after adding a node may result in data inconsistencies including resurrection of previously deleted data.
DataStax recommends stopping repair operations during topology changes; the Repair Service does this automatically. Repairs running during a topology change are likely to error when it involves moving ranges.
-
If migrating from the
PropertyFileSnitch
to theGossipingPropertyFileSnitch
in DSE 5.1.0 to 5.1.7, remove thecassandra-topology.properties
file from each node on any new cluster after the migration is complete.
Next steps
Here’s background information and related details to help you understand the snitch behavior for the DSE 5.1 and 6.x releases:
|