Thanks for the confirmation Kurt
Le 6 nov. 2018 11:59, "kurt greaves" a écrit :
> Yes it does. Consider if it didn't and you kept writing to the same
> partition, you'd never be able to remove any tombstones for that partition.
>
> On Tue., 6 Nov. 2018, 19:40 DuyHai Doan
>> Hello all
>>
>> I ha
Hi All,
I have 3 node (A,B,C) 2.1.16 cassandra cluster which i am upgrading to
cassandra 3.11.2.
My current cluster status is node a has been upgrade to 3.11.2, B is down,
and C is on cassandra 2.1.16
when i run counter update using cqlsh it is behaving strange inconsistent
way , sometimes the up
Yes it does. Consider if it didn't and you kept writing to the same
partition, you'd never be able to remove any tombstones for that partition.
On Tue., 6 Nov. 2018, 19:40 DuyHai Doan Hello all
>
> I have tried to sum up all rules related to tombstone removal:
>
>
> --
Cassandra will execute such request using a Partition Range Scan.
See more details here http://www.doanduyhai.com/blog/?p=13191, chapter E
Cluster Read Path (look at the formula of Concurrency Factor)
On Tue, Nov 6, 2018 at 8:21 AM shalom sagges wrote:
> Hi All,
>
> If I run for example:
> se
Hello all
I have tried to sum up all rules related to tombstone removal:
--
Given a tombstone written at timestamp (t) for a partition key (P) in
SSTable (S1). This tombstone will be removed:
1) after gc_grace_secon
