Re: Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-07-01 Thread Jeff Jirsa
RF=5 allows you to lose two hosts without losing quorum Many teams can calculate their hardware failure rate and replacement time. If you can do both of these things you can pick and RF that meets your durability and availability SLO. For sufficiently high SLOs you’ll need RF > 3 > On Jun 30,

Re: Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-06-30 Thread Oleksandr Shulgin
On Sat, Jun 29, 2019 at 5:49 AM Jeff Jirsa wrote: > If you’re at RF= 3 and read/write at quorum, you’ll have full visibility > of all data if you switch to RF=4 and continue reading at quorum because > quorum if 4 is 3, so you’re guaranteed to overlap with at least one of the > two nodes that got

Re: Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-06-28 Thread Jeff Jirsa
If you’re at RF= 3 and read/write at quorum, you’ll have full visibility of all data if you switch to RF=4 and continue reading at quorum because quorum if 4 is 3, so you’re guaranteed to overlap with at least one of the two nodes that got all earlier writes Going from 3 to 4 to 5 requires a re

Re: Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-06-28 Thread Oleksandr Shulgin
On Fri, Jun 28, 2019 at 11:29 PM Jeff Jirsa wrote: > you often have to run repair after each increment - going from 3 -> 5 > means 3 -> 4, repair, 4 -> 5 - just going 3 -> 5 will violate consistency > guarantees, and is technically unsafe. > Jeff, How going from 3 -> 4 is *not violating* consi

Re: Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-06-28 Thread Jon Haddad
Yep - not to mention the increased complexity and overhead of going from ONE to QUORUM, or the increased cost of QUORUM in RF=5 vs RF=3. If you're in a cloud provider, I've found you're almost always better off adding a new DC with a higher RF, assuming you're on NTS like Jeff mentioned. On Fri,

Re: Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-06-28 Thread Jeff Jirsa
For just changing RF: You only need to repair the full token range - how you do that is up to you. Running `repair -pr -full` on each node will do that. Running `repair -full` will do it multiple times, so it's more work, but technically correct.The caveat that few people actually appreciate about

Running Node Repair After Changing RF or Replication Strategy for a Keyspace

2019-06-28 Thread Fd Habash
Hi all … The datastax & apache docs are clear: run ‘nodetool repair’ after you alter a keyspace to change its RF or RS. However, the details are all over the place as what type of repair and on what nodes it needs to run. None of the above doc authorities are clear and what you find on the int