Re: Alter table

If you use collections such as a map you could get by with just upserts. A collection in a column gives you the ability to have “flexible” schema for your “documents” as in mongo while the regular fields can act as “records” as in a more Traditional table. Rahul Singh Chief Executive Officer m

Re: Alter table

Alter table would change columns (the structure) of a table. Adding or deleting a column, for instance. Upserts would add (or edit) rows of an existing table. ALTER TABLE vs. UPDATE

Re: Alter table

(My advice stands, I still believe it to be safe in all modern versions not impacted by 13004, but) There’s little difference between adding columns and removing columns - if you’re afraid of writes while you add columns, you should be afraid of writes while you remove columns. (But I don’t

Re: Alter table

Thanks for all the inputs! We’ll stick to the current approach then. How about dropping columns - If we also stop writes beforehand, we should be safe from data alignment issue after dropping columns? Thanks, Li > On Jul 31, 2018, at 04:14, James Shaw wrote: > > in a heavy transaction PROD

Re: Alter table

in a heavy transaction PROD env, it is risk, considering c* has a lot of bugs. the DDL has to be replicated to all nodes, use nodetool describecluster to check schema version same on all nodes, if not, you may restart that node which DDL not replicated. in new version, DDL is none or all, you

Re: Alter table

This is safe (and normal, and good) in all versions except those impacted by https://issues.apache.org/jira/browse/CASSANDRA-13004 So if you're on 2.1, 2.2, or 3.11 you're fine If you're on 3.0 between 3.0.0 and 3.0.13, you should upgrade first (to newest 3.0, probably 3.0.17) If you're on a

Re: Alter table gc_grace_seconds

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). >

Re: Alter table gc_grace_seconds

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. >>

Re: Alter table gc_grace_seconds

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':

Re: Alter table gc_grace_seconds

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

RE: Alter table gc_grace_seconds

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 previously de

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

+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

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

Re: Alter table gc_grace_seconds

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 (

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

* 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

Re: Alter table gc_grace_seconds

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,

Re: Alter table gc_grace_seconds

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" : [ ] }

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

* 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

Re: Alter table gc_grace_seconds

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

Re: Alter table gc_grace_seconds

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

Re: alter table issues on 2.0.10

I found this JIRA with similar error message ( https://issues.apache.org/jira/browse/CASSANDRA-6276), not sure it applies to your case, and especially the issue is supposed to be fixed in 2.0.10 (your current version). Consider filling a new JIRA if you can reproduce the issue On Mon, Oct 13,

Re: alter table issues on 2.0.10

Hi, it actually seems to be worse than what I thought; I get an exception in cassandra logs every time I try to create a new table. Cql query: CREATE TABLE shard12 (feed_id ascii, activity_id timeuuid, activities blob, created_at timestamp, group ascii, updated_at timestamp, seen_at timestamp,

Re: alter table issues on 2.0.10

Here is the full stack trace ERROR [Native-Transport-Requests:5802] 2014-10-12 22:48:12,237 QueryMessage.java (line 131) Unexpected error during query java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException:

Re: Alter table drop column seems not working

You are right, the documentation says that this action is not supported. I was surprised because the auto completion in cqlsh allows you to try it and, moreover, you have an example of a drop column when you use help alter_drop. Maybe it would be nice to change at least the documentation and

Re: Alter table drop column seems not working

I dont think it's supported http://www.datastax.com/docs/1.2/cql_cli/cql/ALTER_TABLE#dropping-typed-col Anyone else know? Cheers - Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 3/04/2013, at 8:11 PM, julien Campan