x27;re on 3.0 between 3.0.0 and 3.0.13, you should upgrade first (to
>> newest 3.0, probably 3.0.17)
>> If you're on a version between 3.1 and 3.10, you should upgrade first (to
>> newest 3.11, probably 3.11.3)
>>
>> - Jeff
>>
>>
>>> On M
Hi all,
I have one question about altering schema. If we only add columns, is it ok to
alter the schema while the writes to the table are happening at the same time?
We can control that the writes will not touch the new columns until the schema
change is done. Or better to stop the writes to th
Hi Mick,
Thanks for replying!
I did not reset repairedAt and ran repair with -pr directly. That’s probably
why the inconsistency occurred.
As our tables are pretty big, full repair takes many days to finish. Given the
10 days gc period, it means repair almost will run all the time. Consistency
;
>> On Wed., 4 Jul. 2018, 06:41 Visa, wrote:
>> Hi all,
>>
>> We recently experienced an unexpected behavior with C* consistency.
>>
>> For example, a table t consists of 4 columns - pk , a, b and c. We perform
>> Quorum write and then Quorum read (RF=3
; On Wed., 4 Jul. 2018, 06:41 Visa, wrote:
>> Hi all,
>>
>> We recently experienced an unexpected behavior with C* consistency.
>>
>> For example, a table t consists of 4 columns - pk , a, b and c. We perform
>> Quorum write and then Quorum read (RF=3 / LCS comp
Hi all,
We recently experienced an unexpected behavior with C* consistency.
For example, a table t consists of 4 columns - pk , a, b and c. We perform
Quorum write and then Quorum read (RF=3 / LCS compaction).
The consistency seems to break while repairing is running(repair -pr).
Say, a record
