releases 3.0.25 and 3.11.11. Once released, skip
directly from 3.0.22 to 3.0.25 or from 3.11.8 to 3.11.11. For those
already on the affected versions, the Cassandra community is working
to release 3.0.25 and 3.11.11 immediately. Immediate upgrade to 3.0.25
or 3.11.11 is recommended and all schema
Having said that, I'm still not a fan of making schema changes
programmatically. I spend way too much time helping users unscramble their
schema after they've hit multiple disagreements. I do understand the need
for it but avoid it if you can particularly in production.
On Fri, 4 Jun
>
> I wonder if there’s a way to query the driver to see if your schema change
> has fully propagated. I haven’t looked into this.
>
Yes, the drivers have APIs for this. For example, the Java driver has
isSchemaInAgreement() and checkSchemaAgreement().
See
https://docs.datastax.com/en/developer/
we setup the schema to match the code that is
>>> about to be tested. This can mean multiple CI runners each adding/dropping
>>> tables at the same time but for different key spaces.
>>>
>>>
>>> Our experience is even though the s
ébastien.
>>
>> Le mar. 1 juin 2021 à 05:21, Max C. a écrit :
>>
>>> In our case we have a shared dev cluster with (for example) a key space
>>> for each developer, a key space for each CI runner, etc. As part of
>>> initializing our test suite we setu
t;> initializing our test suite we setup the schema to match the code that is
>> about to be tested. This can mean multiple CI runners each adding/dropping
>> tables at the same time but for different key spaces.
>>
>> Our experience is even though the schema changes do
ven though the schema changes do not conflict,
we still run into schema mismatch problems. Our solution to
this was to have a lock (external to Cassandra) that ensures only
a single schema change operation is being issued at a time.
People assume schema changes in Cassandra wor
s can mean multiple CI runners each adding/dropping
> tables at the same time but for different key spaces.
>
> Our experience is even though the schema changes do not conflict, we still
> run into schema mismatch problems. Our solution to this was to have a lock
> (external to C
zing our test suite we setup the schema to match the code that is
> about to be tested. This can mean multiple CI runners each adding/dropping
> tables at the same time but for different key spaces.
>
> Our experience is even though the schema changes do not conflict, we still
>
tables at the
same time but for different key spaces.
Our experience is even though the schema changes do not conflict, we still run
into schema mismatch problems. Our solution to this was to have a lock
(external to Cassandra) that ensures only a single schema change operation is
being issued
ing policy with only 1 host specified), this
way your schemas changes will be serialized and you will avoid issues and
race conditions
2016-11-15 19:04 GMT+01:00 Josh Smith :
> Would someone please explain how schema changes happen?
>
> Here are some of the ring details
>
> We ha
can start here:
>
> https://issues.apache.org/jira/browse/CASSANDRA-10699
>
> And here:
>
> http://stackoverflow.com/questions/20293897/cassandra-
> resolution-of-concurrent-schema-changes
>
> In a nutshell, schema changes works best when issued serially, when all
> nodes are u
You can start here:
https://issues.apache.org/jira/browse/CASSANDRA-10699
And here:
http://stackoverflow.com/questions/20293897/cassandra-resolution-of-concurrent-schema-changes
In a nutshell, schema changes works best when issued serially, when all
nodes are up, and reachable. When these 3
Would someone please explain how schema changes happen?
Here are some of the ring details
We have 5 nodes in 1 DC and 5 nodes in another DC across the country.
Here is our problem, we have a tool which automates our schema creation. Our
schema consists of 7 keyspaces with 21 tables in each
y, you have nothing to do. Changes will be synced to every nodes
>> automatically.
>>
>> 2015-03-12 13:21 GMT+08:00 Ajay :
>>
>>> Hi,
>>>
>>> Are there any steps to do (like nodetool or restart node) or any
>>> precautions after schem
Hi,
>>
>> Are there any steps to do (like nodetool or restart node) or any
>> precautions after schema changes are done in a column family say adding a
>> new column or modifying any table properties?
>>
>> Thanks
>> Ajay
>>
>
>
>
> --
> Thanks,
> Phil Yang
>
>
Usually, you have nothing to do. Changes will be synced to every nodes
automatically.
2015-03-12 13:21 GMT+08:00 Ajay :
> Hi,
>
> Are there any steps to do (like nodetool or restart node) or any
> precautions after schema changes are done in a column family say adding a
> new colu
Hi,
Are there any steps to do (like nodetool or restart node) or any
precautions after schema changes are done in a column family say adding a
new column or modifying any table properties?
Thanks
Ajay
Good morning,
Sorry for the slow reply here. I finally had some time to test cqlsh tracing on
a ccm cluster with 2 of 3 nodes down, to see if the unavailable error was due
to cqlsh or my query. Reply inline below.
On 15/01/2015 12:46, "Tyler Hobbs"
mailto:ty...@datastax.com>> wrote:
On Thu, J
On Thu, Jan 15, 2015 at 6:30 AM, Richard Dawe
wrote:
>
> I thought it might be quorum consistency level, because of the because I
> was seeing with cqlsh. I was testing with ccm with C* 2.0.8, 3 nodes,
> vnodes enabled ("ccm create test -v 2.0.8 -n 3 --vnodes -s”). With all
> three nodes up, my
e the schema migration is sent to
the other nodes in the cluster, to understand what the requirements are for
successfully applying the update. E.g.: is QUORUM consistency level applied?
A quorum isn't required. Schema changes are simply applied against the local
node (whichever node th
el
> applied?
>
A quorum isn't required. Schema changes are simply applied against the
local node (whichever node the client sends the query to) and then are
pushed out to the other nodes. Nodes will also pull the latest schema from
other nodes as needed (for example, if a node was down
Hello,
I’m doing some research on schema migrations for Cassandra.
I’ve been playing with cqlsh with TRACING ON, and I can see that a schema
change like “CREATE TABLE” is sent to all nodes in the cluster. And also that
“CREATE TABLE” fails if only one of my three nodes is up (with replication
one node and
> the metadata read to another, and because it takes some time for the table
> creation to propagate across all of the nodes in my cluster.
>
> What is the best way to deal with this problem? Is there a standard way to
> wait for schema changes to propagate?
>
&g
for the table creation to propagate across all of the nodes in my cluster.
>
> What is the best way to deal with this problem? Is there a standard way
> to wait for schema changes to propagate?
>
> Best regards,
> Clint
>
--
Ben Bromhead
Instaclustr | www.instaclustr.com | @instaclustr
<http://twitter.com/instaclustr> | +61 415 936 359
create-table request to
one node and the metadata read to another, and because it takes some time
for the table creation to propagate across all of the nodes in my cluster.
What is the best way to deal with this problem? Is there a standard way to
wait for schema changes to propagate?
Best regards
What clients are the scripts using ? This sounds like something that should be
handled in the client.
I would worry about holding a long running connection to a single node. There
are several situations where the correct behaviour for a client is to kill a
connection and connect to another nod
Hi Dave,
Thank you for your answer.
2012/5/25 Dave Brosius
> What version are you using?
>
I am using version 1.1.0
> It might be related to
> https://issues.apache.org/jira/browse/CASSANDRA-4052
>
Indeed the Issue you suggested goes into the direction of my problem.
However, things are a
What version are you using?
It might be related to https://issues.apache.org/jira/browse/CASSANDRA-4052
On 05/25/2012 07:32 AM, Victor Blaga wrote:
Hi all,
This is my first message on this posting list so I'm sorry if I am
breaking any rules. I just wanted to report some sort of a problem
th
Hi all,
This is my first message on this posting list so I'm sorry if I am breaking
any rules. I just wanted to report some sort of a problem that I'm having
with Cassandra.
Short version of my problem: if I make changes to the schema from within a
process, they do not get picked up by the other p
Cool, thanks. I suspected the same, including the repair.
On 08/20/2010 06:05 AM, Gary Dusbabek wrote:
It is coming. In fact, I started working on this ticket yesterday.
Most of the settings that you could change before will be modifiable.
Unfortunately, you must still manually perform the re
It is coming. In fact, I started working on this ticket yesterday.
Most of the settings that you could change before will be modifiable.
Unfortunately, you must still manually perform the repair operations,
etc., afterward.
https://issues.apache.org/jira/browse/CASSANDRA-1285
Gary.
On Thu, Aug
f_defs(cfDefs);
c.system_add_keyspace(k);
/Justus
www.justus.st
Från: Andres March [mailto:ama...@qualcomm.com]
Skickat: den 20 augusti 2010 01:01
Till: user@cassandra.apache.org
Ämne: Replication factor and other schema changes in >= 0.7
How should we go about changing the replication factor an
How should we go about changing the replication factor and other
keyspace settings now that it and other KSMetaData are no longer managed
in cassandra.yaml?
I found makeDefinitionMutation() in the Migration class and see that it
is called for the other schema migrations. There just seems to
34 matches
Mail list logo
