Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of stryuber@gmail.com designates
 209.85.223.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANOBG4z+w7LGXvYJ0s1PWB9JFHkNyQeP_PNkA90W-AfirKR-yg@mail.gmail.com>
References: 
 <CANOBG4z+w7LGXvYJ0s1PWB9JFHkNyQeP_PNkA90W-AfirKR-yg@mail.gmail.com>
From: Sergey Tryuber <stryuber@gmail.com>
Date: Sun, 9 Sep 2012 13:09:17 +0400
Message-ID: 
 <CANOBG4zGuWK+xFiQJJYUgkvzPs=w8Q4fsBcOSGB-xf8A=K6cMA@mail.gmail.com>
Subject: Replication factor 2, consistency and failover
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=14dae934032b49fb8804c94133d5

--14dae934032b49fb8804c94133d5
Content-Type: text/plain; charset=UTF-8

Hi

We have to use Cassandra with RF=2 (don't ask why...). There are two
datacenters (RF=2 in each datacenter). Also we use Astyanax as a client
library. In general we want to achieve strong consistency. Read performance
is important for us, that's why we perform writes with LOCAL_QUORUM and
reads with ONE. If one server is down, we automatically switch to
Writes.ONE, Reads.ONE only for that replica which has failed node (we
modified Astyanax to achieve that). When the server comes back, we turn
back Writes.LOCAL_QUORUM and Reads.ONE, but, of course, we see some
inconsistencies during the switching process and some time after (when
hinted handnoff works).

Basically I don't have any questions, just want to share our "ugly"
failover algorithm, to hear your criticism and may be advise on how to
improve it. Unfortunately we can't change replication factor and most of
the time we have to read with consistency level ONE (because we have strict
requirements on read performance).

Thank you!

--14dae934032b49fb8804c94133d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">Hi<br><br>We have to use Cassandra with RF=3D2 (=
don&#39;t ask why...). There are two datacenters (RF=3D2 in each datacenter=
). Also we use Astyanax as a client library. In general we want to achieve =
strong consistency. Read performance is important for us, that&#39;s why we=
 perform writes with LOCAL_QUORUM and reads with ONE. If one server is down=
, we automatically switch to Writes.ONE, Reads.ONE only for that replica wh=
ich has failed node (we modified Astyanax to achieve that). When the server=
 comes back, we turn back Writes.LOCAL_QUORUM and Reads.ONE, but, of course=
, we see some inconsistencies during the switching process and some time af=
ter (when hinted handnoff works).<br>


<br>Basically I don&#39;t have any questions, just want to share our &quot;=
ugly&quot; failover algorithm, to hear your criticism and may be advise on =
how to improve it. Unfortunately we can&#39;t change replication factor and=
 most of the time we have to read with consistency level ONE (because we ha=
ve strict requirements on read performance). <br>


<br>Thank you!<br>
</div><br>

--14dae934032b49fb8804c94133d5--