> So when I am performing a QUORUM write on cluster with RF=3 and one node > fails, I will get write error status and one successful write on another node. > If you lost one node during or before a write at QUOURM and RF 3 the write would succeed without any error to the client.
> write will be propagated to other nodes when they became online; Yes this is hinted hand off. > write can be completely lost if the node accepted that write will be > completely broken before propagation. Yes *if* atomic batches are not used http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2 They are used by default for CQL 3 and require a separate call over the thrift API. > What is the best ways to deal with such kind of fails in let say hypothetical > funds transfer logging? > You should watch / read the talk from Matt Dennis on data modelling here http://www.datastax.com/company/news-and-events/events/cassandrasummit2012/presentations Cheers ----------------- Aaron Morton Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 12/08/2013, at 12:27 AM, Arthur Zubarev <[email protected]> wrote: > Hello Mikhail, > > The bullet 1 implies consistency, but at later time. And you don't lose the > transaction. By the way, RF 3 to support financials is too low. > > #2, if the entire disk (that had no parity) fails you lost this write, but > the 3rd node would have the write. > > Again, having a greater CF is the key. > > Regards, > > Arthur > > > > -------- Original message -------- > From: Mikhail Tsaplin <[email protected]> > Date: 08/10/2013 12:13 PM (GMT-05:00) > To: [email protected] > Subject: Handling quorum writies fails > > > Hi. > > According to Datastax documentation about atomicity in Cassandra: QUORUM > write succeeded only on one node will not be rolled back (Check Atomicity > chapter > there:http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/dml/dml_about_transactions_c.html). > So when I am performing a QUORUM write on cluster with RF=3 and one node > fails, I will get write error status and one successful write on another > node. This produces two cases: > > write will be propagated to other nodes when they became online; > write can be completely lost if the node accepted that write will be > completely broken before propagation. > What is the best ways to deal with such kind of fails in let say hypothetical > funds transfer logging? >
