Yep, you can fix it by running repair or even faster by changing the consistency level to local_quorum and deploying the new version of the app.
Hannu > On 8 Sep 2016, at 17:51, Benyi Wang <bewang.t...@gmail.com> wrote: > > Thanks Hannu, > > Unfortunately, we started changing RF from 2 to 3, and did see the empty > result rate is going higher. I assume that "If the LOCAL_ONE read hit the > new replica which is not there yet, the CQL query will return nothing." Is my > assumption correct? > > On Thu, Sep 8, 2016 at 11:49 AM, Hannu Kröger <hkro...@gmail.com > <mailto:hkro...@gmail.com>> wrote: > Hi, > > If you change RF=2 -> 3 first, the LOCAL_ONE reads might hit the new replica > which is not there yet. So I would change LOCAL_ONE -> LOCAL_QUORUM first and > then change the RF and then run the repair. LOCAL_QUORUM is effectively ALL > in your case (RF=2) if you have just one DC, so you can change the batch CL > later. > > Cheers, > Hannu > > > On 8 Sep 2016, at 14:42, Benyi Wang <bewang.t...@gmail.com > > <mailto:bewang.t...@gmail.com>> wrote: > > > > * I have a keyspace with RF=2; > > * The client read the table using LOCAL_ONE; > > * There is a batch job loading data into the tables using ALL. > > > > I want to change RF to 3 and both the client and the batch job use > > LOCAL_QUORUM. > > > > My question is "Will the client still read the correct data when the repair > > is running at the time my batch job loading is running too?" > > > > Or should I change to LOCAL_QUORUM first? > > > > Thanks. > >
