Re: Purge data from repair_history table?
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?
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?
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?
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?
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