We’re pleased to announce that Reaper 2.2 for Apache Cassandra was just released. This release includes a major redesign of how segments are orchestrated, which allows users to run concurrent repairs on nodes. Let’s dive into these changes and see what they mean for Reaper’s users.
In a previous blog post recommending disabling read repair chance, some flamegraphs were generated to demonstrate the effect read repair chance had on a cluster. Let’s go through how those flamegraphs were captured, step-by-step using Apache Cassandra 3.11.6, Kubernetes and the cass-operator, nosqlbench and the async-profiler.
Apache Cassandra’s default value for
num_tokens is about to change in 4.0! This might seem like a small edit note in the CHANGES.txt, however such a change can have a profound effect on day-to-day operations of the cluster. In this post we will examine how changing the value for
num_tokens impacts the cluster and its behaviour.
Apache Cassandra has a feature called Read Repair Chance that we always recommend our clients to disable. It is often an additional ~20% internal read load cost on your cluster that serves little purpose and provides no guarantees.
I’m happy, excited, and extremely proud to announce The Last Pickle has been acquired by DataStax.
Reaper is our tool for managing repairs for Apache Cassandra.
tlp-stress is our tool for benchmarking Apache Cassandra clusters.
tlp-cluster is our tool for quickly provisioning Apache Cassandra clusters for test purposes.