If you have two replicas A and B, and you write at ONE

A acknowledged the write, B is running but drops write, the write succeeds

A fails 30 seconds later. The data is lost because it had no chance to be 
repaired to the other host via hints / repair / readrepair

10 days is a big window - repair is a smaller problem than RF=2 and writing at 
ONE
-- 
Jeff Jirsa


> On Jun 9, 2018, at 10:52 PM, onmstester onmstester <onmstes...@zoho.com> 
> wrote:
> 
> Thanks Jeff,
> If i run repair every 10 days, then, would there be a chance of losing data 
> by losing one node (data inserted exactly after last repair) ? 
> 
> Sent using Zoho Mail
> 
> 
> 
> ---- On Sun, 10 Jun 2018 10:14:46 +0430 Jeff Jirsa <jji...@gmail.com> wrote 
> ----
> 
> 
> 
> 
> On Jun 9, 2018, at 10:28 PM, onmstester onmstester <onmstes...@zoho.com> 
> wrote:
> 
> I'm using RF=2 (i know it should be at least 3 but i'm short of resources) 
> and WCl=ONE and RCL=ONE in a cluster of 10 nodes in a insert-only scenario. 
> The problem: i dont want to use nodetool repair because it would put hige 
> load on my cluster for a long time, but also i need data consistency
> and fault tolerance in a way that:
> if one of my nodes fails:
> 1. there would be no single record data loss
> 
> This requires write > 1
> 
> 2. write/read of data would be continued with no problem
> 
> 
> This requires more replicas in the ring than the number of replicas requires 
> for reads and writes
> 
> 
> I know that current config won't satisfy No.1, so changed the Write 
> Consistensy Level to ALL and to satisfy No.2, i'm catching exceptions of
> "1 replicas needed but 2 required", write those records again with WCL = ONE 
> and put them somewhere for rewrite later with WCL=2.
> Is there anything wrong with this workaround? any better solution (Strong 
> requirements: I can't change the RF, The system should tolerate 1 node 
> failure with no data loss and no read/write failure) 
> 
> 
> Sorta works, but it’s dirty and a lot of edge cases. Depending on the budget 
> and value of data, maybe it’s ok, but I wouldn’t trust it to be good enough 
> for critical use cases
> 
> The transient replication work that Ariel is doing 
> (https://issues.apache.org/jira/browse/CASSANDRA-14404) will likely benefit 
> you here in 4.0 (but it will require you to run repair).
> 
> 

Reply via email to