Re: Alter table

202.905.2818 Anant Corporation 1010 Wisconsin Ave NW, Suite 250 Washington, D.C. 20007 We build and manage digital business technology platforms. On Dec 17, 2018, 4:45 PM -0500, Mark Furlong , wrote: > Why would I want to use alter table vs upserts with the new document format? > > Mar

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 <https://docs.scylladb.com/getting-started/ddl/#id10> vs. UPDATE <https://docs.scylladb.com/getting-started/dm

Alter table

Why would I want to use alter table vs upserts with the new document format? Mark Furlong Sr. Database Administrator mfurl...@ancestry.com<mailto:mfurl...@ancestry.com> M: 801-859-7427 O: 801-705-7115 1300 W Traverse Pkwy Lehi, UT 84043 ​[http://c.mfcreative.com/mars/email/shared-ic

Re: Corrupt insert during ALTER TABLE add

Yep, that’s the problem! Thanks Jeff (and Alex Petrov for fixing it). - Max > On Sep 13, 2018, at 1:24 pm, Jeff Jirsa wrote: > > CASSANDA-13004 (fixed in recent 3.0 and 3.11 builds) - To unsubscribe, e-mail:

Re: Corrupt insert during ALTER TABLE add

CASSANDA-13004 (fixed in recent 3.0 and 3.11 builds) On Thu, Sep 13, 2018 at 1:12 PM Max C. wrote: > I ran “alter table” today to add the “task_output_capture_state” column > (see below), and we found a few rows inserted around the time of the ALTER > TABLE did not contain the same va

Re: Corrupt insert during ALTER TABLE add

Correction — we’re running C* 3.0.8. DataStax Python driver 3.4.1. > On Sep 13, 2018, at 1:11 pm, Max C. wrote: > > I ran “alter table” today to add the “task_output_capture_state” column (see > below), and we found a few rows inserted around the time of the ALTER TABLE >

Corrupt insert during ALTER TABLE add

I ran “alter table” today to add the “task_output_capture_state” column (see below), and we found a few rows inserted around the time of the ALTER TABLE did not contain the same values when selected as when they were inserted. When the row was selected, what we saw was: - test_id —> OK (s

Re: Alter table

escribecluster 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 may not get it success. >> >> It is similar to rdbms, alter table in a heavy transaction PROD env,

Re: Alter table

ay not get it success. > > It is similar to rdbms, alter table in a heavy transaction PROD env, may get > resource busy error. > > in non-prod, we always apply new DDL without stop applications, never had > issue. > > Thanks, > > James > > >> On T

Re: Alter table

may not get it success. It is similar to rdbms, alter table in a heavy transaction PROD env, may get resource busy error. in non-prod, we always apply new DDL without stop applications, never had issue. Thanks, James On Tue, Jul 31, 2018 at 1:37 AM, Jeff Jirsa wrote: > This is s

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

Alter table

Hi all, I have one question about altering schema. If we only add columns, is it ok to alter the schema while the writes to the table are happening at the same time? We can control that the writes will not touch the new columns until the schema change is done. Or better to stop the writes to

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 <varunbaral...@gmail.com> 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 compa

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

quot;1" ], "deletion_info" : { "marked_deleted" : "2017-10-01T17:30:15.397Z", "local_delete_time" : "2017-10-01T17:30:15Z" }, "cells" : [ ] } ] } *# performed compaction to compact above two sstables (l

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 <auth.ga...@gmail.com> wrote: > Hi, > > The `alter table number_item with gc_grace_seconds = 3600;` is sets the

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

Alter table gc_grace_seconds

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

ALTER TABLE implementation details

Hi! I'm using Cassandra 2.2 for my home-grown SAAS and currently evaluating prospect of adding columns to tables on user requests. So I have a couple of questions regarding ALTER TABLE statement: 1) how adding/removing columns implemented on cluster level? 2) in case of column addition how soon

Re: CQL Alter table does not propagate to all nodes.

Lu, Thanks for the letting me know that you figured it out. Cheers, Erick

Re: CQL Alter table does not propagate to all nodes.

fine. My instances are on AWS and I think I should adjust the phi_convict_threshold property higher. -- View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/CQL-Alter-table-does-not-propagate-to-all-nodes-tp7597211p7597242.html Sent from the cassandra-u

Re: alter table issues on 2.0.10

: comparators do not match or are not compatible. Tommaso 2014-10-12 13:05 GMT+02:00 tommaso barbugli tbarbu...@gmail.com: Hi, I am seeing errors every time I make a schema migration of this kind on cassandra 2.0.10 ALTER TABLE notifications add unread_ids settimeuuid static ErrorMessage

CQL Alter table does not propagate to all nodes.

I have a 3-node cluster running Cassandra 2.0.6 on CentOS 6.5, with Jave 1.7.0_51. I ran a CQL statement like alter table table_name with gc_grace_seconds=864000; on node 1 in CQLSH, and it finished instantaneously. desc keyspace listed the table with the new value for gc_grace_seconds

Re: CQL Alter table does not propagate to all nodes.

Hello, dlu66061. A common issue with schema disagreements is time drift on the nodes. Are you using NTP? The only other issue is when the nodes are not reachable at the time that the schema update was being propagated ---

alter table issues on 2.0.10

Hi, I am seeing errors every time I make a schema migration of this kind on cassandra 2.0.10 ALTER TABLE notifications add unread_ids settimeuuid static ErrorMessage code= [Server error] message=java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException

Re: alter table issues on 2.0.10

2.0.10 ALTER TABLE notifications add unread_ids settimeuuid static ErrorMessage code= [Server error] message=java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: org.apache.cassandra.exceptions.ConfigurationException: comparators do not match

Re: alter table issues on 2.0.10

, I am seeing errors every time I make a schema migration of this kind on cassandra 2.0.10 ALTER TABLE notifications add unread_ids settimeuuid static ErrorMessage code= [Server error] message=java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException

Re: Schema disagreement under normal conditions, ALTER TABLE hangs

Thanks Rob. Let me add one thing in case someone else finds this thread - Restarting the nodes did not in and of itself get the schema disagreement resolved. We had to run the ALTER TABLE command individually on each of the disagreeing nodes once they came back up. On Tuesday, November 26

Re: Schema disagreement under normal conditions, ALTER TABLE hangs

schema updates issued. Going to the nodes with stale schema and trying to do the ALTER TABLE there resulted in hanging. We were eventually able to get schema agreement by restarting nodes, but both the initial disagreement under normal conditions and the hanging ALTER TABLE seem pretty weird. Any

Schema disagreement under normal conditions, ALTER TABLE hangs

to do the ALTER TABLE there resulted in hanging. We were eventually able to get schema agreement by restarting nodes, but both the initial disagreement under normal conditions and the hanging ALTER TABLE seem pretty weird. Any ideas here? Sound like a bug? We're on 1.2.8. Thanks, Josh -- Josh

Re: Alter table drop column seems not working

uuid, id_avatar_3 uuid, id_avatar_4 uuid ) ; cqlsh ALTER TABLE cust DROP id_avatar_1 ; ==Bad Request: line 1:17 no viable alternative at input 'DROP' ==Perhaps you meant to use CQL 2? Try using the -2 option when ==starting cqlsh. Can someone tell me how to drop a column

Re: Alter table drop column seems not working

julien.cam...@gmail.com wrote: Hi, I'm working with cassandra 1.2.2. When I try to drop a column , it's not working. This is what I tried : CREATE TABLE cust ( ise text PRIMARY KEY, id_avatar_1 uuid, id_avatar_2 uuid, id_avatar_3 uuid, id_avatar_4 uuid ) ; cqlsh ALTER