What are your read repair settings?

On Tue, Sep 8, 2015 at 9:28 PM, Eric Plowe <eric.pl...@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.pl...@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 <rc...@eventbrite.com> wrote:
>>
>>> On Tue, Sep 8, 2015 at 4:40 PM, Eric Plowe <eric.pl...@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
>>>
>>>

Reply via email to