Apologies if this is an obvious question, I have looked but not seen too much (particularly about what exactly "latest version" means when there is no data on a node for a key - though I'd assume it has to be treated as "unknown" since you couldn't tell if the data had never been created or the tombstone had been cleaned up)
We are moving some stuff from prototype towards production. We have a new Cassandra 2.0 instance; 6 nodes. I'm using Astyanax 1.56.43 from Java via thrift, though we see the same thing with CQL 3 from node client 1) So the problem here is likely caused by one of our nodes maybe being in a "dead" state but not recognized as such - that is something we need to figure out… any suggestions on determine root cause here would be a help; I only have access to OpCenter which tells me little (except this one node was growing in size, whilst others weren't, and NO keyspaces have replication factor 1, so that seems odd even if keys were skewed which they aren't). Anyway that isn't the main question; I can follow up with our ops guys when they are online 2) I saw the problem when I "fixed" our read code to use QUORUM consistency level not ONE (the Astyanax default); it only affects some keys. The problem is a timeout exception. I assume that it is not getting a response from this one node. (I have read that 2.0.2 may have something that would help this resolve itself quicker) - note I had also seen some slow schema resolution today also Anyways, I can work around the problem with a ONE consistency level it seems, but I did have a more general question: - Our writes are all idempotent in so far as keyspace/cf/(key/column) may be written more than once but only with the same value. We use QUORUM writes (will be LOCAL_QUORUM as soon as we configure server to be DC aware), and that is fine. The point being, I wonder if there is something between ONE and QUORUM read consistency level that I could specify in my situation to return as soon as any node returns a non tombstone value? Thanks, Graham P.S. If not has this been discussed and dismissed - it would seem like a common case that people write data only once, and because of upstream replay/transactional behavior may want a cassandra write to be an idempotent side effect.
smime.p7s
Description: S/MIME cryptographic signature
