Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <AANLkTinGWiWTChCy_uUjGgDh_dwejEcWJuoyZOb4ExUY@mail.gmail.com>
References: <AANLkTinGWiWTChCy_uUjGgDh_dwejEcWJuoyZOb4ExUY@mail.gmail.com>
Date: Mon, 20 Sep 2010 18:42:03 +0200
Message-ID: <AANLkTinZ7OF5h5YvfHTHXet1mJE4pdETX1gZyUOBQypb@mail.gmail.com>
Subject: Re: commit log question
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> =C2=A0=C2=A0 I have one question about the 'commit log' in Cassandra, so =
imagine
> we issue a write with QUORUM, if the write was successful then we are
> sure that N/2 +1 replicas have the new data.=C2=A0If one of these replica=
s
> fail, no state is lost because the state is also available from
> another machine in the cluster. Do we really need in this case a
> durable commit log at all in this case, it should be a very rare case
> to need it?

It's a matter of what kind of durability you're after. If you want
data to be truly committed and persistent even in the phase of e.g.
power outages then you want data to be truly persistent. If you don't,
you don't. It think whether or not the commit log is durable is
somewhat orthogonal to whether you're using QUOROM or not since you
may e.g. have a use-case for durable writes at CL.ONE in cases where
you need the durability (and are perhaps fine trusting the RAID on one
node) but not the immediate consistency with respect to reads.

In any case, if you're truly concerned with not loosing data that was
supposedly written, don't underestimate the very real possibilities of
e.g. power outages affecting multiple writes or even entire data
centers.

--=20
/ Peter Schuller