il Sergio’s thread. It just was something that
> caught my interest and got me mulling, but it’s a tangent.
>
>
>
> *From: *Erick Ramirez
> *Reply-To: *"user@cassandra.apache.org"
> *Date: *Friday, February 14, 2020 at 9:04 PM
> *To: *"user@cassandra.apache.org&q
my interest and got me mulling, but it’s a tangent.
From: Erick Ramirez
Reply-To: "user@cassandra.apache.org"
Date: Friday, February 14, 2020 at 9:04 PM
To: "user@cassandra.apache.org"
Subject: Re: AWS I3.XLARGE retiring instances advices
Message from External Sender
Eric
>
> Erick, a question purely as a point of curiosity. The entire model of a
> commit log, historically (speaking in RDBS terms), depended on a notion of
> stable store. The idea being that if your data volume lost recent writes,
> the failure mode there would be independent of writes to the
13, 2020 at 10:46 PM
To: "user@cassandra.apache.org"
Subject: Re: AWS I3.XLARGE retiring instances advices
A little off-topic but personally I would co-locate the commitlog on the same
950GB NVMe SSD as the data files. You would get a much better write performance
from the nodes compared t
the
missing data. I’d be curious what the C* expert viewpoint on that would be,
with the commit log and data on the same volume.
From: Sergio
Reply-To: "user@cassandra.apache.org"
Date: Thursday, February 13, 2020 at 10:46 PM
To: "user@cassandra.apache.org"
Subject: Re: AW
Feels that way and most people don’t do it, but definitely required for strict
correctness.
> On Feb 13, 2020, at 8:57 PM, Erick Ramirez wrote:
>
>
> Interesting... though it feels a bit extreme unless you're dealing with a
> cluster that's constantly dropping mutations. In which case,
Interesting... though it feels a bit extreme unless you're dealing with a
cluster that's constantly dropping mutations. In which case, you have
bigger problems anyway. :)
Option 1 is only strictly safe if you run repair while the down replica is
down (otherwise you validate quorum consistency guarantees)
Option 2 is probably easier to manage and wont require any special effort
to avoid violating consistency.
I'd probably go with option 2.
On Thu, Feb 13, 2020
Thank you for the advices!
Best!
Sergio
On Thu, Feb 13, 2020, 7:44 PM Erick Ramirez
wrote:
> Option 1 is a cheaper option because the cluster doesn't need to rebalance
> (with the loss of a replica) post-decommission then rebalance again when
> you add a new node.
>
> The hints directory on
Option 1 is a cheaper option because the cluster doesn't need to rebalance
(with the loss of a replica) post-decommission then rebalance again when
you add a new node.
The hints directory on EBS is irrelevant because it would only contain
mutations to replay to down replicas if the node was a
10 matches
Mail list logo
