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

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

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

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

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