Re: How do TTLs generate tombstones

[kurt greaves]

No it's never safe to set it to 0 as you'll disable hinted handoff for the
table. If you are never doing updates and manual deletes and you always
insert with a ttl you can get away with setting it to the hinted handoff
period.

On 6 Oct. 2017 1:28 am, "eugene miretsky"  wrote:

> Thanks Jeff,
>
> Make sense.
> If we never use updates (time series data), is it safe to set
> gc_grace_seconds=0.
>
>
>
> On Wed, Oct 4, 2017 at 5:59 PM, Jeff Jirsa  wrote:
>
>>
>> The TTL'd cell is treated as a tombstone. gc_grace_seconds applies to
>> TTL'd cells, because even though the data is TTL'd, it may have been
>> written on top of another live cell that wasn't ttl'd:
>>
>> Imagine a test table, simple key->value (k, v).
>>
>> INSERT INTO table(k,v) values(1,1);
>> Kill 1 of the 3 nodes
>> UPDATE table USING TTL 60 SET v=1 WHERE k=1 ;
>> 60 seconds later, the live nodes will see that data as deleted, but when
>> that dead node comes back to life, it needs to learn of the deletion.
>>
>>
>>
>> On Wed, Oct 4, 2017 at 2:05 PM, eugene miretsky <
>> eugene.miret...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> The following link says that TTLs generate tombstones -
>>> https://docs.datastax.com/en/cql/3.3/cql/cql_using/useExpire.html.
>>>
>>> What exactly is the process that converts the TTL into a tombstone?
>>>
>>>1. Is an actual new tombstone cell created when the TTL expires?
>>>2. Or, is the TTLed cell treated as a tombstone?
>>>
>>>
>>> Also, does gc_grace_period have an effect on TTLed cells?
>>> gc_grace_period is meant to protect from deleted data re-appearing if the
>>> tombstone is compacted away before all nodes have reached a consistent
>>> state. However, since the ttl is stored in the cell (in liveness_info),
>>> there is no way for the cell to re-appear (the ttl will still be there)
>>>
>>> Cheers,
>>> Eugene
>>>
>>>
>>
>

LCS major compaction on 3.2+ on JBOD

[Dan Kinder]

Hi

I am wondering how major compaction behaves for a table using LCS on JBOD
with Cassandra 3.2+'s JBOD improvements.

Up to then I know that major compaction would use a single thread, include
all SSTables in a single compaction, and spit out a bunch of SSTables in
appropriate levels.

Does 3.2+ do 1 compaction per disk, since they are separate leveled
structures? Or does it do a single compaction task that writes SSTables to
the appropriate disk by key range?

-dan

Calculate tokens from date range

[Harika Vangapelli -T (hvangape - AKRAYA INC at Cisco)]

We have data in tables with partitioning key as 'Timestamp' and we are in need 
of running repairs for last 3 months data because full repair is taking lot of 
time.
We are migrating data from Cassandra version 2 to 3.

Please guide us with your best suggestions.

Thanks

[http://wwwin.cisco.com/c/dam/cec/organizations/gmcc/services-tools/signaturetool/images/logo/logo_gradient.png]



Harika Vangapelli
Engineer - IT
hvang...@cisco.com
Tel:

Cisco Systems, Inc.



United States
cisco.com


[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here for 
Company Registration Information.

[RELEASE] Apache Cassandra 2.2.11 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.2.11.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.2 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt) https://goo.gl/QcJrD8
[2]: (NEWS.txt) https://goo.gl/abKrHt
[3]: https://issues.apache.org/jira/browse/CASSANDRA



signature.asc
Description: OpenPGP digital signature

[RELEASE] Apache Cassandra 2.1.19 released

[Michael Shuler]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 2.1.19.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 2.1 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

Enjoy!

[1]: (CHANGES.txt) https://goo.gl/EfNTLV
[2]: (NEWS.txt) https://goo.gl/MYajtt
[3]: https://issues.apache.org/jira/browse/CASSANDRA



signature.asc
Description: OpenPGP digital signature

Re: How do TTLs generate tombstones

[eugene miretsky]

Thanks Jeff,

Make sense.
If we never use updates (time series data), is it safe to set
gc_grace_seconds=0.



On Wed, Oct 4, 2017 at 5:59 PM, Jeff Jirsa  wrote:

>
> The TTL'd cell is treated as a tombstone. gc_grace_seconds applies to
> TTL'd cells, because even though the data is TTL'd, it may have been
> written on top of another live cell that wasn't ttl'd:
>
> Imagine a test table, simple key->value (k, v).
>
> INSERT INTO table(k,v) values(1,1);
> Kill 1 of the 3 nodes
> UPDATE table USING TTL 60 SET v=1 WHERE k=1 ;
> 60 seconds later, the live nodes will see that data as deleted, but when
> that dead node comes back to life, it needs to learn of the deletion.
>
>
>
> On Wed, Oct 4, 2017 at 2:05 PM, eugene miretsky  > wrote:
>
>> Hello,
>>
>> The following link says that TTLs generate tombstones -
>> https://docs.datastax.com/en/cql/3.3/cql/cql_using/useExpire.html.
>>
>> What exactly is the process that converts the TTL into a tombstone?
>>
>>1. Is an actual new tombstone cell created when the TTL expires?
>>2. Or, is the TTLed cell treated as a tombstone?
>>
>>
>> Also, does gc_grace_period have an effect on TTLed cells? gc_grace_period
>> is meant to protect from deleted data re-appearing if the tombstone is
>> compacted away before all nodes have reached a consistent state. However,
>> since the ttl is stored in the cell (in liveness_info), there is no way for
>> the cell to re-appear (the ttl will still be there)
>>
>> Cheers,
>> Eugene
>>
>>
>

Re: table repair question

[Javier Canillas]

I'm doing it on a daily basis. If the repaired percentage drops from 80%,
then I do a repair over that keyspace-table. Seems working fine for the
last months without problems and avoids huge merkle tree building. No data
loss so far.

I'm running 3.11.0 btw.

2017-10-04 17:44 GMT-03:00 Blake Eggleston :

> Incremental repairs should also update the percentage, although I'd
> recommend not using incremental repair before 4.0. Just want to point out
> that running repairs based on repaired % isn't necessarily a bad thing, but
> it should be a secondary consideration. The important thing is to repair
> data more frequently than your gc grace period.
>
>
> On October 4, 2017 at 1:33:57 PM, Javier Canillas (
> javier.canil...@gmail.com) wrote:
>
> That percentage will only be updated if you do a full repair. If you do
> repairs on local dc or with -pr, that percentage will not be updated.
>
> I scripted a regular repair on each node based on if this percentage is
> below some threshold. It has been running fine since several months ago.
>
> 2017-10-04 12:46 GMT-03:00 Blake Eggleston :
>
>> Not really no. There's a repaired % in nodetool tablestats if you're
>> using incremental repair (and you probably shouldn't be before 4.0 comes
>> out), but I wouldn't make any decisions based off it's value.
>>
>>
>> On October 4, 2017 at 8:05:44 AM, ZAIDI, ASAD A (az1...@att.com) wrote:
>>
>> Hello folk,
>>
>>
>>
>> I’m wondering if there is way to find out list of table(s) which need
>> repair OR if there Is way to find out what %age of data would need to be
>> repaired on a table?  Is such information available from Cassandra  db
>> engine through some other means?
>>
>>
>>
>> TIA~ Asad
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: CREATE INDEX without IF NOT EXISTS when snapshoting

[Javier Canillas]

Well,

Patches submitted for version 3.0, 3.11 and trunk (although 3.0 patch can
be applied to 3.11). Feel free to review and comment.

Thanks!

2017-10-04 16:41 GMT-03:00 Javier Canillas :

> Kurt,
>
> Thanks for your response. Created this ticket
> . Feel free to add
> anything to it that seems legit.
>
> Downloading Cassandra code right now.
>
> Fix seems quite simple. Expect a pull-request soon xD
>
> 2017-10-03 20:19 GMT-03:00 kurt greaves :
>
>> Certainly would make sense and should be trivial.  here
>> 
>>  is
>> where you want to look. Just create a ticket for it and prod here for a
>> reviewer once you've got a change.​
>>
>
>

Re: Alter table gc_grace_seconds

[Gábor Auth]

Hi,

On Wed, Oct 4, 2017 at 8:39 AM Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:

> If you have migrated ALL the data from the old CF, you could just use
> TRUNCATE or DROP TABLE, followed by "nodetool clearsnapshot" to reclaim the
> disk space (this step has to be done per-node).
>

Unfortunately not all the data migrated, but to CFs came from one CF:
"only" the 80% for data migrated to another CF.

At the moment, the compaction works with:
compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '2'} AND gc_grace_seconds = 172800

But I don't know why it did not work and why it works now... :)

Bye,
Auth Gábor