Hello Laxmiant, your application has to deal with eventually consistency if you are using cassandra. Ensure to have
R + W > RF And have the repairs runing periodically. This is the best way to be the most cosistent and coherent Jean Carlo "The best way to predict the future is to invent it" Alan Kay On Thu, Jan 16, 2020 at 3:18 PM Laxmikant Upadhyay <laxmikant....@gmail.com> wrote: > Hi Alex, > > You are right, that will solve the problem. but unfortunately i won't be > able to meet my sla with write each quorum . I am using local quorum for > both read and write. > Any other way ? > > > On Thu, Jan 16, 2020, 5:45 PM Oleksandr Shulgin < > oleksandr.shul...@zalando.de> wrote: > >> On Thu, Jan 16, 2020 at 1:04 PM Laxmikant Upadhyay < >> laxmikant....@gmail.com> wrote: >> >>> Hi, >>> What I meant fromActive/standby model is that even though data is being >>> replicated (asynchronously) to standby DC , client will only access the >>> data from active DC (let's say using local_quorum). >>> >>> you have "to switch" your clients without any issues since your writes >>> are replicated on all DC. >>> --> that is not true because there is a chance of mutation drop. (Hints, >>> read repair may help to some extent but data consistency is not guaranteed >>> unless you run anti- entropy repair ) >>> >> >> What are the consistency levels used by your application(s)? >> >> E.g. for strong consistency across multiple DCs you could use EACH_QUORUM >> for the write requests and LOCAL_QUORUM for reads, with a replication >> factor >= 3 per DC. >> >> -- >> Alex >> >>
