Best strategy to run repair

Hi, We are on open source 3.11.5 . We need to repair a production cluster . We are using num_token as 256 . What will be a better option to run repair ? 1. nodetool -pr (Primary range repair on all nodes, one node at a time) OR 2. nodetool -st -et (Subrange repair , taking the ranges for each

Re: Best strategy to run repair

-pr on all nodes takes much longer as you'll do at least triple the amount of merkle calculations I believe (with RF 3) and tends to be quite problematic. Subrange is the way to go, which is what cassandra-reaper will do for you if you have it set up. raft.so - Cassandra consulting, support, and

Re: Best strategy to run repair

Also try to use Cassandra reaper (as Kane also mentioned) for subrange repair. Doing subrange repair yourself may lead to a lot of trouble as calculating correct subranges is not an easy task. On Tue, Mar 23, 2021 at 3:38 AM Kane Wilson wrote: > -pr on all nodes takes much longer as you'll do

Re: Best strategy to run repair

If you can pick ranges on your own correctly, then you can do that way. In my opinion a ready made tested solution is available, I think it should be used. On Tue, Mar 23, 2021 at 10:55 AM Surbhi Gupta wrote: > Does describering not give the correct sub ranges for each node ? > > On Mon, 22

Re: Best strategy to run repair

Does describering not give the correct sub ranges for each node ? On Mon, 22 Mar 2021 at 20:28, manish khandelwal < manishkhandelwa...@gmail.com> wrote: > Also try to use Cassandra reaper (as Kane also mentioned) for subrange > repair. Doing subrange repair yourself may lead to a lot of trouble

Re: Changing num_tokens and migrating to 4.0

On 2021-03-22 01:27, Kane Wilson wrote: You should be able to get repairs working fine if you use a tool such as cassandra-reaper to manage it for you for such a small cluster. I would look into that before doing major cluster topology changes, as these can be complex and risky. I was

RE: Changing num_tokens and migrating to 4.0

I have a cluster (almost 200 nodes) with a variety of disk sizes and use different numbers of tokens so that the machines can use the disk they have. It is a very handy feature! While I agree that a node with larger disk may handle more requests, that may not be enough to impact CPU or memory.