Re: Purge data from repair_history table?

2017-03-20 Thread Jonathan Haddad 
default_time_to_live is a convenience parameter that automatically applies
a TTL to incoming data.  Every field that's inserted can have a separate
TTL.

The TL;DR of all this is that changing default_time_to_live doesn't change
any existing data retroactively.  You'd have to truncate the table if you
want to drop the old data.

On Mon, Mar 20, 2017 at 12:06 PM Gábor Auth  wrote:

> Hi,
>
> On Fri, Mar 17, 2017 at 2:22 PM Paulo Motta 
> wrote:
>
> It's safe to truncate this table since it's just used to inspect repairs
> for troubleshooting. You may also set a default TTL to avoid it from
> growing unbounded (this is going to be done by default on CASSANDRA-12701).
>
>
> I've made an alter on the repair_history and the parent_repair_history
> tables:
> ALTER TABLE system_distributed.repair_history WITH compaction =
> {'class':'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy',
> 'compaction_window_unit':'DAYS', 'compaction_window_size':'1'
> } AND default_time_to_live = 2592000;
>
> Is it affect the previous contents in the table or I need to truncate
> manually? Is the 'TRUNCATE' safe? :)
>
> Bye,
> Gábor Auth
>

Re: Purge data from repair_history table?

2017-03-20 Thread Gábor Auth 
Hi,

On Fri, Mar 17, 2017 at 2:22 PM Paulo Motta 
wrote:

> It's safe to truncate this table since it's just used to inspect repairs
> for troubleshooting. You may also set a default TTL to avoid it from
> growing unbounded (this is going to be done by default on CASSANDRA-12701).
>

I've made an alter on the repair_history and the parent_repair_history
tables:
ALTER TABLE system_distributed.repair_history WITH compaction =
{'class':'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy',
'compaction_window_unit':'DAYS', 'compaction_window_size':'1'
} AND default_time_to_live = 2592000;

Is it affect the previous contents in the table or I need to truncate
manually? Is the 'TRUNCATE' safe? :)

Bye,
Gábor Auth

Re: Purge data from repair_history table?

2017-03-17 Thread Gábor Auth 
Oh, thanks! :)

On Fri, 17 Mar 2017, 14:22 Paulo Motta,  wrote:

> It's safe to truncate this table since it's just used to inspect repairs
> for troubleshooting. You may also set a default TTL to avoid it from
> growing unbounded (this is going to be done by default on CASSANDRA-12701).
>
> 2017-03-17 8:36 GMT-03:00 Gábor Auth :
>
> Hi,
>
> I've discovered a relative huge size of data in the system_distributed
> keyspace's repair_history table:
>Table: repair_history
>Space used (live): 389409804
>Space used (total): 389409804
>
> What is the purpose of this data? There is any safe method to purge? :)
>
> Bye,
> Gábor Auth
>
>
>

Re: Purge data from repair_history table?

2017-03-17 Thread Paulo Motta 
It's safe to truncate this table since it's just used to inspect repairs
for troubleshooting. You may also set a default TTL to avoid it from
growing unbounded (this is going to be done by default on CASSANDRA-12701).

2017-03-17 8:36 GMT-03:00 Gábor Auth :

> Hi,
>
> I've discovered a relative huge size of data in the system_distributed
> keyspace's repair_history table:
>Table: repair_history
>Space used (live): 389409804
>Space used (total): 389409804
>
> What is the purpose of this data? There is any safe method to purge? :)
>
> Bye,
> Gábor Auth
>
>

Purge data from repair_history table?

2017-03-17 Thread Gábor Auth 
Hi,

I've discovered a relative huge size of data in the system_distributed
keyspace's repair_history table:
   Table: repair_history
   Space used (live): 389409804
   Space used (total): 389409804

What is the purpose of this data? There is any safe method to purge? :)

Bye,
Gábor Auth