Hi,
On Wed, Oct 4, 2017 at 8:39 AM Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> If you have migrated ALL the data from the old CF, you could just use
> TRUNCATE or DROP TABLE, followed by "nodetool clearsnapshot" to reclaim the
> disk space (this step has to be done per-node).
>
Un
On Sun, Oct 1, 2017 at 4:14 PM, Gábor Auth wrote:
> Hi,
>
> On Sun, Oct 1, 2017 at 3:44 PM Varun Barala
> wrote:
>
>> This is the property of table and It's not written in sstables. If you
>> change gc_grace, It'll get applied for all the data.
>>
>
> Hm... I've migrated lot of data from `number
Hi,
On Mon, Oct 2, 2017 at 1:43 PM Varun Barala wrote:
> Either you can change min_threshold to three in your case or you can
> change compaction strategy for this table.
>
I've changed:
alter table number_item with compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompaction
lto: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 complet
ect: 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 pre
Hi,
On Mon, Oct 2, 2017 at 8:41 AM Varun Barala wrote:
> Might be possible C* is not compacting the sstables [
> https://stackoverflow.com/questions/28437301/cassandra-not-compacting-sstables
> ]
>
Oh, the other CF-s in the same keyspace are compacted, but the
`number_item` not.
[cassandra@dc0
Hi,
On Mon, Oct 2, 2017 at 8:32 AM Justin Cameron
wrote:
> >> * 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 tha
+1 Justing,
Might be possible C* is not compacting the sstables [
https://stackoverflow.com/questions/28437301/cassandra-not-compacting-sstables
].
You can this fact by doing below procedure:-
*Run this before compaction:-*
ls /var/lib/cassandra/data/mat/number_item-*/
Store result to some file
>> * 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
Hi,
On Mon, Oct 2, 2017 at 5:55 AM Varun Barala 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,
Can you share result of query:-
*select gc_grace_seconds from system_schema.tables where keyspace_name =
'keyspace' and table_name = 'number_item;*
Thanks!!
On Mon, Oct 2, 2017 at 3:42 AM, Gábor Auth wrote:
> Hi,
>
> On Sun, Oct 1, 2017 at 9:36 PM Varun Barala
> wrote:
>
>> * You should not t
Hi,
On Sun, Oct 1, 2017 at 9:36 PM Varun Barala wrote:
> * You should not try on real clusters directly.
>
Why not? :)
Did you change gc_grace for all column families?
>
Not, only on the `number_item` CF.
> But not in the `number_item` CF... :(
> Could you please explain?
>
I've tried the t
* You should not try on real clusters directly.
Did you change gc_grace for all column families?
> But not in the `number_item` CF... :(
Could you please explain?
Thanks!!
On Mon, Oct 2, 2017 at 2:24 AM, Gábor Auth wrote:
> Hi,
>
> On Sun, Oct 1, 2017 at 7:44 PM Varun Barala
> wrote:
>
>> So
Hi,
On Sun, Oct 1, 2017 at 7:44 PM Varun Barala wrote:
> Sorry If I misunderstood the situation.
>
Ok, I'm confused... :/
I've just tested it on the same cluster and the compact removed the
marked_deleted rows. But not in the `number_item` CF... :(
Cassandra 3.11.0, two DC (with 4-4 nodes).
Sorry If I misunderstood the situation.
{
"type" : "row",
"position" : 146160,
"clustering" : [ "humidity", "97781fd0-9dab-11e7-a3d5-7f6ef9a844c7" ],
"deletion_info" : { "marked_deleted" : "2017-09-25T11:51:19.165276Z",
"local_delete_time" : "2017-09-25T11:51:19Z" },
"cells" : [ ]
}
H
Hi,
On Sun, Oct 1, 2017 at 6:53 PM Jonathan Haddad wrote:
> The TTL is applied to the cells on insert. Changing it doesn't change the
> TTL on data that was inserted previously.
>
Is there any way to purge out these tombstoned data?
Bye,
Gábor Auth
Hi,
On Sun, Oct 1, 2017 at 6:53 PM Jonathan Haddad wrote:
> The TTL is applied to the cells on insert. Changing it doesn't change the
> TTL on data that was inserted previously.
>
Oh! So that the tombstoned cell's TTL is equals with the CF's
gc_grace_seconds value and the repair will be remove
The TTL is applied to the cells on insert. Changing it doesn't change the
TTL on data that was inserted previously.
On Sun, Oct 1, 2017 at 6:23 AM Gábor Auth wrote:
> Hi,
>
> The `alter table number_item with gc_grace_seconds = 3600;` is sets the
> grace seconds of tombstones of the future modif
* Which C* version are you using?
* How many nodes are there in this cluster?
These tombstones will not be deleted if they are not older than
gc_grace_seconds.
On Sun, Oct 1, 2017 at 10:14 PM, Gábor Auth wrote:
> Hi,
>
> On Sun, Oct 1, 2017 at 3:44 PM Varun Barala
> wrote:
>
>> This is the pr
Hi,
On Sun, Oct 1, 2017 at 3:44 PM Varun Barala wrote:
> This is the property of table and It's not written in sstables. If you
> change gc_grace, It'll get applied for all the data.
>
Hm... I've migrated lot of data from `number_item` to `measurement` CF
because of scheme upgrade. During the m
Hi,
This is the property of table and It's not written in sstables. If you
change gc_grace, It'll get applied for all the data. Thanks!!
C* stores this info inside schema_columnfamilies
Regards,
Varun Barala
On Sun, Oct 1, 2017 at 9:23 PM, Gábor Auth wrote:
> Hi,
>
> The `alter table number_it
Hi,
The `alter table number_item with gc_grace_seconds = 3600;` is sets the
grace seconds of tombstones of the future modification of number_item
column family or affects all existing data?
Bye,
Gábor Auth
22 matches
Mail list logo
