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 will 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:


  1. Steps for switching snitches:

  2. Create a properties file with datacenter and rack information.

  3. Copy the cassandra-rackdc.properties or cassandra-topology.properties file to the configuration directory on all the cluster’s nodes. They won’t be used until the new snitch is enabled.

  4. Change the snitch for each node in the cluster in the node’s cassandra.yaml file. For example:

    endpoint_snitch: GossipingPropertyFileSnitch
  5. 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.

  6. If the topology of the network has changed, but no datacenters are added:

    1. Shut down all the nodes, then restart them.

    2. Run a sequential repair and nodetool cleanup on each node.

      Failure to run nodetool cleanup after adding a node may result in data inconsistencies including resurrection of previously deleted data.

  7. If the topology of the network has changed and a datacenter is added:

    1. Create a new datacenter.

    2. Replicate data into new datacenter. Remove nodes from old datacenter.

    3. Run a sequential repair and nodetool cleanup on each node.

      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.

      Failure to run nodetool cleanup after adding a node may result in data inconsistencies including resurrection of previously deleted data.

  8. If migrating from the PropertyFileSnitch to the GossipingPropertyFileSnitch, remove the cassandra-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:

  • Normally when setting the snitch to GossipingPropertyFileSnitch, the file that the snitch reads is cassandra-rackdc.properties.

  • However, in Apache Cassandra and in DSE releases up to DSE 5.1, GossipingPropertyFileSnitch instead reads values in cassandra-topology.properties, if that file is present. This behavior is called "compatibility mode."

  • Starting from DSE 5.1.8+ and DSE 6.0.0+, and applicable to subsequent releases (DSE 6.7.x and DSE 6.9.x), the following changes are in effect:

    • Snitch compatibility mode is disabled

    • By default, GossipingPropertyFileSnitch ignores the cassandra-topology.properties file

    • Optionally, you can set the following specific Java property to true at DSE startup, to enable compatibility mode and have GossipingPropertyFileSnitch read from the cassandra-topology.properties file:


  • The GossipingPropertyFileSnitch behavior is summarized in the DSE log, when DSE 6.x starts:

    GossipingPropertyFileSnitch.java:87 - Property file snitch compatibility mode is disabled. Set startup property cassandra.gpfs.enable_pfs_compatibility_mode=true to enable.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com