Hello Justin, yes, but in real-world, hard to accomplish for high volume column families >= 3-digit GB. Even with the default of 10 days grace period, this may get a real challenge, to complete a full repair. ☺
Possibly back again to the discussion that incremental repair has some flaws, full repair (-full option) in 3.0+ (2.2+?) isn’t behaving the same way as in 2.1 anymore, due to troubles when kicking off with –pr on several nodes at once. Regards, Thomas From: Justin Cameron [mailto:jus...@instaclustr.com] Sent: Montag, 02. Oktober 2017 08:32 To: user@cassandra.apache.org Subject: Re: Alter table gc_grace_seconds >> * You should not try on real clusters directly. >Why not? :) It's highly recommended that you complete a full repair before the GC grace period expires, otherwise it's possible you could experience zombie data (i.e. data that was previously deleted coming back to life) See http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html for a good overview of the problem On Mon, 2 Oct 2017 at 16:51 Gábor Auth <auth.ga...@gmail.com<mailto:auth.ga...@gmail.com>> wrote: Hi, On Mon, Oct 2, 2017 at 5:55 AM Varun Barala <varunbaral...@gmail.com<mailto:varunbaral...@gmail.com>> wrote: select gc_grace_seconds from system_schema.tables where keyspace_name = 'keyspace' and table_name = 'number_item; cassandra@cqlsh:mat> DESCRIBE TABLE mat.number_item; CREATE TABLE mat.number_item ( nodeid uuid, type text, created timeuuid, value float, PRIMARY KEY (nodeid, type, created) ) WITH CLUSTERING ORDER BY (type ASC, created ASC) AND bloom_filter_fp_chance = 0.01 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND cdc = false AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 3600 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; cassandra@cqlsh:mat> select gc_grace_seconds from system_schema.tables where keyspace_name = 'mat' and table_name = 'number_item'; gc_grace_seconds ------------------ 3600 (1 rows) Bye, Gábor Auth -- Justin Cameron Senior Software Engineer [Image removed by sender.]<https://www.instaclustr.com/> This email has been sent on behalf of Instaclustr Pty. Limited (Australia) and Instaclustr Inc (USA). This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistädterstraße 313
