incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Talbot <btal...@aeriagames.com>
Subject Re: update does not apply to any replica if consistency = ALL and one replica is down
Date Fri, 17 May 2013 18:30:55 GMT
I think you're conflating "may" with "must".  That article says that
updates "may" still be applied to some replicas when there is a failure and
I believe that still is the case.  However, if the coordinator knows that
the CL can't be met before even attempting the write, I don't think it will
attempt the write.

-Bryan



On Fri, May 17, 2013 at 1:48 AM, Sergey Naumov <sknaumov@gmail.com> wrote:

> As described here (
> http://maxgrinev.com/2010/07/12/update-idempotency-why-it-is-important-in-cassandra-applications-2/),
> if consistency level couldn't be met, updates are applied anyway on
> functional replicas, and they could be propagated later to other replicas
> using repair mechanisms or by issuing the same request later, as update
> operations are idempotent in Cassandra.
>
> But... on my configuration (Cassandra 1.2.4, python CQL 1.0.4, DC1 - 3
> nodes, DC2 - 3 nodes, DC3 - 1 node, RF={DC1:3, DC2:2, DC3:1}, Random
> Partitioner, GossipingPropertyFileSnitch, one node in DC1 is deliberately
> down - and, as RF for DC1 is 3, this down node is a replica node for 100%
> of records),  when I try to insert one record with consistency level of
> ALL, this insert does not appear on any replica (-s30 - is a serial of
> UUID1: 0000001e-0000-1000-0000-xxxxxxxxxxxxx (30 is 1e in hex), -n1 mean
> that we will insert/update a single record with first id from this series -
> 0000001e-0000-1000-0000-000000000000):
> *write with consistency ALL:*
> cassandra@host11:~/Cassandra$ ./insert.sh -s30 -n1 -cALL
> Traceback (most recent call last):
>   File "./aux/fastinsert.py", line 54, in insert
>     curs.execute(cmd, consistency_level=p.conlvl)
> OperationalError: Unable to complete request: one or more nodes were
> unavailable.
> Last record UUID is 0000001e-0000-1000-0000-000000000000*
>
> *
> about 10 seconds passed...
> *
> read with consistency ONE:*
> cassandra@host11:~/Cassandra$ ./select.sh -s30 -n1 -cONE
> Total records read: *0*
> Last record UUID is 0000001e-0000-1000-0000-000000000000
> *read with consistency QUORUM:*
> cassandra@host11:~/Cassandra$ ./select.sh -s30 -n1 -cQUORUM
> Total records read: *0*
> Last record UUID is 0000001e-0000-1000-0000-000000000000
> *write with consistency QUORUM:*
> cassandra@host11:~/Cassandra$ ./insert.sh -s30 -n1 -cQUORUM
> Last record UUID is 0000001e-0000-1000-0000-000000000000
> *read with consistency QUORUM:*
> cassandra@host11:~/Cassandra$ ./select.sh -s30 -n1 -cQUORUM
> Total records read: *1*
> Last record UUID is 0000001e-0000-1000-0000-000000000000
>
> Is it a new feature of Cassandra that it does not perform a write to any
> replica if consistency couldn't be satisfied? If so, then is it true for
> all cases, for example when returned error is "OperationalError: Request
> did not complete within rpc_timeout"?
>
> Thanks in advance,
> Sergey Naumov.
>

Mime
View raw message