With Apache Cassandra 4.0 just around the corner, and the feature freeze on trunk lifted, let’s take a dive into the efforts ongoing with the project’s testing and Continuous Integration systems.
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.
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.