some updates but pretty infrequent. this thing should be super
>>> fast, on avg it's like 1 to 2ms p99 currently but if they double - triple
>>> the traffic on that table latencies go upward to 20ms to 50ms.. the only
>>> odd thing i see is just that there are constant rea
t;
>>
>>
>>
>>
>>
>> *From:* Patrick Lee [mailto:patrickclee0...@gmail.com]
>> *Sent:* Wednesday, October 16, 2019 12:22 PM
>> *To:* user@cassandra.apache.org
>> *Subject:* Re: Constant blocking read repair for such a tiny table
>>
>>
ee0...@gmail.com]
> *Sent:* Wednesday, October 16, 2019 12:22 PM
> *To:* user@cassandra.apache.org
> *Subject:* Re: Constant blocking read repair for such a tiny table
>
>
>
> haven't really figured this out yet. it's not a big problem but it is
> annoying for s
atrick Lee [mailto:patrickclee0...@gmail.com]
Sent: Wednesday, October 16, 2019 12:22 PM
To: user@cassandra.apache.org
Subject: Re: Constant blocking read repair for such a tiny table
haven't really figured this out yet. it's not a big problem but it is annoying
for sure! the cluster w
On Thu, Oct 3, 2019 at 4:21 PM John Belliveau
>>> wrote:
>>>
>>>> Hi Patrick,
>>>>
>>>>
>>>>
>>>> Is this time series data? If so, I have run into issues with repair on
>>>> time series data using the SizeTieredCo
ve had
>>> better luck using the TimeWindowCompactionStrategy.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>&
0986> for
>> Windows 10
>>
>>
>>
>> *From: *Patrick Lee
>> *Sent: *Thursday, October 3, 2019 5:14 PM
>> *To: *user@cassandra.apache.org
>> *Subject: *Constant blocking read repair for such a tiny table
>>
>>
>>
>> I have a cl
986> for
> Windows 10
>
>
>
> *From: *Patrick Lee
> *Sent: *Thursday, October 3, 2019 5:14 PM
> *To: *user@cassandra.apache.org
> *Subject: *Constant blocking read repair for such a tiny table
>
>
>
> I have a cluster that is running 3.11.4 ( was upg
PM
To: user@cassandra.apache.org
Subject: Constant blocking read repair for such a tiny table
I have a cluster that is running 3.11.4 ( was upgraded a while back from 2.1.16
). what I see is a steady rate of read repair which is about 10% constantly on
only this 1 table. Repairs have been run
I have a cluster that is running 3.11.4 ( was upgraded a while back from
2.1.16 ). what I see is a steady rate of read repair which is about 10%
constantly on only this 1 table. Repairs have been run (actually several
times). The table does not have a lot of writes to it so after repair, or
even
10 matches
Mail list logo