cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Varun Barala <varunbaral...@gmail.com>
Subject Re: Alter table gc_grace_seconds
Date Mon, 02 Oct 2017 11:43:21 GMT
https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfigureCompaction.html

As pe STCS:
*This strategy triggers a minor compaction when there are a number of
similar sized SSTables on disk as configured by the table subproperty,
min_threshold.*
In your case you have *min_threshold=4 and 3 Big sstable and one small
sstable.*
Either you can change min_threshold to three in your case or you can change
compaction strategy for this table.

Thanks!!

On Mon, Oct 2, 2017 at 4:48 PM, Steinmaurer, Thomas <
thomas.steinmaurer@dynatrace.com> wrote:

> 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. J
>
>
>
> 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:justin@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.gabor@gmail.com> wrote:
>
> Hi,
>
> On Mon, Oct 2, 2017 at 5:55 AM Varun Barala <varunbarala99@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: 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
> <https://maps.google.com/?q=4040+Linz,+Austria,+Freist%C3%A4dterstra%C3%9Fe+313&entry=gmail&source=g>
>

Mime
View raw message