> 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 This insert will fail to start and the client will get an UnavailableException.
You are asking for ALL replicas to be available but have disabled one. It's easier to use QUOURM and QUOURM. Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 18/05/2013, at 6:30 AM, Bryan Talbot <btal...@aeriagames.com> wrote: > 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 <sknau...@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. >
