Cluster synchronization settings

Use NodeSync or the OpsCenter Repair Service to maintain cluster synchronization.

The built-in NodeSync feature eliminates the need to run the OpsCenter Repair Service. NodeSync reduces operator complexity and is the recommended solution for cluster synchronization.

NodeSync settings

Enable NodeSync for all relevant keyspaces and tables, and configure the synchronization rate.

Ensure that NodeSync is enabled for all relevant keyspaces and tables through the OpsCenter interface. Monitor NodeSync status and potentially configure the NodeSync rate to ensure that synchronization happens in time allotted by the NodeSync deadline.

Repair Service settings

Use the Repair Service to run repair operations across nodes and their replicas.

When enabled, the Repair Service runs repair operations, which synchronize the most current data across nodes and their replicas, including repairing any corrupted data encountered at the file system level. Once enabled, the Repair Service resumes running where it left off. If this behavior is not desired (for example, when altering tokenranges_partitions), stop and start the Repair Service in the OpsCenter interface to restart synchronization.

Ensure that you are running the latest OpsCenter patch version (6.8.x) when running the Repair Service. Nodes managed by OpsCenter 6.8.x must be running DSE 6.0.0 or later.

Parallel repair operations

Setting the maximum for parallel subrange repairs property controls how many repair operations are issued to the cluster in parallel. This number is computed automatically by dividing the number of nodes by the largest replication factor of any keyspace in the cluster included in the Repair Service. The automatic calculation ensures nodes do not receive multiple repair requests.

This value might need to be tuned manually when keyspaces with a high replication factors exist. However, modifying this value might result in multiple repair requests being sent to a node.

However, ensure that the maximum for parallel subrange repairs is not being automatically calculated to a very low value. This automatic calculation is typically caused by having a keyspace in a cluster with a high replication factor.

Slower repairs

Slowing the progression of the Repair Service might benefit clusters that have a limited amount of data, but can reduce the impact of the Repair Service.

Consider the following advanced Repair Service configurations:

  • Increasing the min_repair_time property (by doubling it or more) allows more time to pass between Repair Service requests.

  • Increasing the time_to_completion_target_percentage throttle property (from current value up to 100) further slows Repair Service tasks.

Faster repairs

Increasing the speed of the Repair Service progression is necessary when a cluster is large or dense, which requires the Repair Service to run more quickly to synchronize the cluster. Increasing the Repair Service speed will increase the load on a cluster due to the increased synchronization activities.

Consider the following changes to increase the speed of the Repair Service:

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,