cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Plowe <eric.pl...@gmail.com>
Subject Re: Question about consistency
Date Wed, 09 Sep 2015 16:11:10 GMT
Yeah, that's what I did. Just wanted to verify it that will indeed turn it
off.

On Wednesday, September 9, 2015, Laing, Michael <michael.laing@nytimes.com>
wrote:

> "alter table test.test_root WITH speculative_retry = '0.0PERCENTILE';"
>
> seemed to work for me with C* version 2.1.7
>
> On Wed, Sep 9, 2015 at 10:11 AM, Eric Plowe <eric.plowe@gmail.com
> <javascript:_e(%7B%7D,'cvml','eric.plowe@gmail.com');>> wrote:
>
>> Would this work:
>>
>> ALTER TABLE session_state WITH speculative_retry = '0ms';
>> ALTER TABLE session_state WITH speculative_retry = '0PERCENTILE';
>>
>> I can't set it to 0, but was wondering if these would have the same
>> effect?
>>
>> ~Eric
>>
>> On Wed, Sep 9, 2015 at 8:19 AM, Eric Plowe <eric.plowe@gmail.com
>> <javascript:_e(%7B%7D,'cvml','eric.plowe@gmail.com');>> wrote:
>>
>>> Interesting. I'll give it a try and report back my findings.
>>>
>>> Thank you, Michael.
>>>
>>>
>>> On Wednesday, September 9, 2015, Laing, Michael <
>>> michael.laing@nytimes.com
>>> <javascript:_e(%7B%7D,'cvml','michael.laing@nytimes.com');>> wrote:
>>>
>>>> Perhaps a variation on
>>>> https://issues.apache.org/jira/browse/CASSANDRA-9753?
>>>>
>>>> You could try setting speculative retry to 0 to avoid cross-dc reads.
>>>>
>>>> On Wed, Sep 9, 2015 at 7:55 AM, Eric Plowe <eric.plowe@gmail.com>
>>>> wrote:
>>>>
>>>>> read_repair_chance: 0
>>>>> dclocal_read_repair_chance: 0.1
>>>>>
>>>>>
>>>>> On Wednesday, September 9, 2015, Laing, Michael <
>>>>> michael.laing@nytimes.com> wrote:
>>>>>
>>>>>> What are your read repair settings?
>>>>>>
>>>>>> On Tue, Sep 8, 2015 at 9:28 PM, Eric Plowe <eric.plowe@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> To further expand. We have two data centers, Miami and Dallas.
>>>>>>> Dallas is our disaster recovery data center. The cluster has
12 nodes, 6 in
>>>>>>> Miami and 6 in Dallas. The servers in Miami only read/write to
Miami using
>>>>>>> data center aware load balancing policy of the driver. We have
the problem
>>>>>>> when writing and reading to the Miami cluster with LOCAL_QUORUM.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> On Tuesday, September 8, 2015, Eric Plowe <eric.plowe@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Rob,
>>>>>>>>
>>>>>>>> All writes/reads are happening from DC1. DC2 is a backup.
The web
>>>>>>>> app does not handle live requests from DC2.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Eric Plowe
>>>>>>>>
>>>>>>>> On Tuesday, September 8, 2015, Robert Coli <rcoli@eventbrite.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, Sep 8, 2015 at 4:40 PM, Eric Plowe <eric.plowe@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I'm using Cassandra as a storage mechanism for session
state
>>>>>>>>>> persistence for an ASP.NET web application. I am
seeing issues
>>>>>>>>>> where the session state is persisted on one page
(setting a value:
>>>>>>>>>> Session["key"] = "value" and when it redirects to
another (from a post back
>>>>>>>>>> event) and check for the existence of the value that
was set, it doesn't
>>>>>>>>>> exist.
>>>>>>>>>>
>>>>>>>>>> It's a 12 node cluster with 2 data centers (6 and
6) running
>>>>>>>>>> 2.1.9. The key space that the column family lives
has a RF of 3
>>>>>>>>>> for each data center. The session state provider
is using the the datastax
>>>>>>>>>> csharp driver v2.1.6. Writes and reads are at LOCAL_QUORUM.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1) Write to DC_A with LOCAL_QUORUM
>>>>>>>>> 2) Replication to DC_B takes longer than it takes to...
>>>>>>>>> 3) Read from DC_B with LOCAL_QUORUM, do not see the write
from 1)
>>>>>>>>>
>>>>>>>>> If you want to be able to read your writes from DC_A
in DC_B,
>>>>>>>>> you're going to need to use EACH_QUORUM.
>>>>>>>>>
>>>>>>>>> =Rob
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>
>

Mime
View raw message