incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Consistency Level of CLI
Date Tue, 23 Mar 2010 01:23:09 GMT
Those are for "majority of replicas in a single datacenter."  The code isn't
quite finished.

2010/3/22 Patricio Echag├╝e <patricioe@gmail.com>

> Hi all, is there any documentation for:
>
>  ConsistencyLevel.DCQUORUM  and  ConsistencyLevel.DCQUORUMSYNC ?
>
> DC = Data Center ?
>
> Thanks
>
>
> On Thu, Feb 25, 2010 at 12:12 PM, Masood Mortazavi <
> masoodmortazavi@gmail.com> wrote:
>
>> From the code, it appears that for "get" the default is ONE.
>>   Column column = thriftClient_.get(tableName, key, path,
>> ConsistencyLevel.ONE).column
>> - m.
>>
>>
>> On Thu, Feb 25, 2010 at 11:08 AM, Masood Mortazavi <
>> masoodmortazavi@gmail.com> wrote:
>>
>>>
>>>
>>> What is the write and read consistency level for the CLI tool
>>> "cassandra-cli" ?
>>>
>>> Do the "set" and "get" commands in the "cli" allow the Consistency Level
>>> to be specified for a given "set" or "get"?
>>>
>>> Is there a current specification of CLI anywhere on the wiki?
>>>
>>> ( How are JIRA's related to the CLI tagged in the JIRA system assuming
>>> they are "tagged" separately? In other words, is there an identifier for
>>> them? )
>>>
>>> Regards,
>>> m.
>>>
>>> ==========================
>>> The Cassandra "API" describes write and read consistency levels as
>>> follows:
>>> http://wiki.apache.org/cassandra/API
>>> Write
>>>
>>> *Level*
>>>
>>> *Behavior*
>>>
>>> ZERO
>>>
>>> Ensure nothing. A write happens asynchronously in background
>>>
>>> ANY
>>>
>>> (Coming in 0.6) Ensure that the write has been written to at least 1
>>> node, including hinted recipients.
>>>
>>> ONE
>>>
>>> Ensure that the write has been written to at least 1 node's commit log
>>> and memory table before responding to the client.
>>>
>>> QUORUM
>>>
>>> Ensure that the write has been written to <ReplicationFactor> / 2 + 1nodes
before responding to the client.
>>>
>>> ALL
>>>
>>> Ensure that the write is written to all <ReplicationFactor> nodes before
>>> responding to the client. Any unresponsive nodes will fail the operation.
>>>
>>> Read
>>>
>>> *Level*
>>>
>>> *Behavior*
>>>
>>> ZERO
>>>
>>> Not supported, because it doesn't make sense.
>>>
>>> ANY
>>>
>>> Not supported. You probably want ONE instead.
>>>
>>> ONE
>>>
>>> Will return the record returned by the first node to respond. A
>>> consistency check is always done in a background thread to fix any
>>> consistency issues when ConsistencyLevel.ONE is used. This means
>>> subsequent calls will have correct data even if the initial read gets an
>>> older value. (This is called read repair.)
>>>
>>> QUORUM
>>>
>>> Will query all storage nodes and return the record with the most recent
>>> timestamp once it has at least a majority of replicas reported. Again, the
>>> remaining replicas will be checked in the background.
>>>
>>> ALL
>>>
>>> Will query all storage nodes and return the record with the most recent
>>> timestamp once all nodes have replied. Any unresponsive nodes will fail the
>>> operatio
>>>
>>>
>>
>
>
> --
> Patricio.-
>

Mime
View raw message