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
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
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
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: user-unsubscr...@
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
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
> did
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 (same
ibecluster 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,
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
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 safe (
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 vers
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 th
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 compac
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).
"clustering" : [ "1", "1" ],
"deletion_info" : { "marked_deleted" : "2017-10-01T17:30:15.397Z",
"local_delete_time" : "2017-10-01T17:30:15Z" },
"cells" : [ ]
}
]
}
*# per
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 tombsto
* 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,
>
&g
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
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
Lu,
Thanks for the letting me know that you figured it out.
Cheers,
Erick
is actually up running 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 fro
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 ---
http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_handl
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
g
ND compaction = {'sstable_size_in_mb': 64,
>>> 'class': 'LeveledCompactionStrategy'};
>>>
>>> This is the error:
>>> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
>>> java.lang.RuntimeException:
>>
eException: java.util.concurrent.ExecutionException:
>> java.lang.RuntimeException:
>> org.apache.cassandra.exceptions.ConfigurationException: comparators do not
>> match or are not compatible.
>>
>> Tommaso
>>
>> 2014-10-12 13:05 GMT+02:00 tommaso barbugli :
ass': 'LeveledCompactionStrategy'};
>
> This is the error:
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.RuntimeException:
> org.apache.cassandra.exceptions.ConfigurationException: comparators do not
> match or are not compatible.
>
> Tommaso
>
> 2014-1
le.
Tommaso
2014-10-12 13:05 GMT+02:00 tommaso barbugli :
> 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" set static
>
> message="java.lang.RuntimeException:
> java.util
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" set static
Weird enough DESCRIBE COLUMNFAMILY notifications; shows that the column
unread_ids is created after the error.
Any idea if this is an
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
tiple
> 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
ng 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,
Jos
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 TABLE cust DROP id_avatar_1 ;
>
> ==>Bad Request: line 1:17 no viable alternative at in
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
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 TABLE cust DROP id_avata
50 matches
Mail list logo
