RE: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

the schema upgraded that much. -- Jacques-Henri Berthemet From: Ken Hancock [mailto:ken.hanc...@schange.com] Sent: mardi 2 février 2016 17:14 To: user@cassandra.apache.org Subject: Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade Just to close the l

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

Hi Ken, Earlier in this thread I posted a link to https://issues.apache.org/jira/browse/CASSANDRA-9424 That is the fix for these schema disagreement issues and as ay commented, the plan is to use CAS. Until then we have to treat schema delicately. all the best, Sebastián On Feb 2, 2016 9:48

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

So this rings odd to me. If you can accomplish the same thing by using a CAS operation, why not fix create table if not exist so that if your are writing an application that creates the table on startup, that the application is safe to run on multiple nodes and uses CAS to safeguard multiple

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

Just to close the loop on this, but am I correct that the IF NOT EXITS isn't the real problem? Even multiple calls to CREATE TABLE cause the same schema mismatch if done concurrently? Normally, a CREATE TABLE call will return an exception that the table already exists. On Tue, Feb 2, 2016 at

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

And CASSANDRA-10699 seems to be the sub-issue of CASSANDRA-9424 to do that: https://issues.apache.org/jira/browse/CASSANDRA-10699 -- Jack Krupansky On Tue, Feb 2, 2016 at 9:59 AM, Sebastian Estevez < sebastian.este...@datastax.com> wrote: > Hi Ken, > > Earlier in this thread I posted a link

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

On 01/22/2016 10:29 PM, Kevin Burton wrote: I sort of agree.. but we are also considering migrating to hourly tables.. and what if the single script doesn't run. I like having N nodes make changes like this because in my experience that central / single box will usually fail at the wrong time

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

There's still a race condition there, because two clients could SELECT at the same time as each other, then both INSERT. You'd be better served with a CAS operation, and let Paxos guarantee at-most-once execution. On Tue, Jan 26, 2016 at 9:06 AM Francisco Reyes wrote: > On

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

You have to wait for schema agreement which most drivers should do by default. At least have a check schema agreement method you can use. https://datastax.github.io/java-driver/2.1.9/features/metadata/ The new cqlsh uses the python driver so the same should apply:

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

It seems like this exact problem pops up every few weeks on this list. I think the documentation does a dangerously bad job of describing the limitations of CREATE TABLE...IF NOT EXISTS. CREATE TABLE...IF NOT EXISTS is a dangerous construct because it seems to advertise atomicity and isolation,

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

+1 for doc update. I added some comments to the seemingly most relevant Jira ticket to confirm best practice that we can then forward to the doc team: https://issues.apache.org/jira/browse/CASSANDRA-10699 -- Jack Krupansky On Mon, Jan 25, 2016 at 1:12 PM, Eric Stevens wrote:

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

CASSANDRA-9424 All the best, [image: datastax_logo.png] Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png]

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

Once the CREATE TABLE returns in cqlsh (or programatically) is it safe to assume it's on all nodes at that point? If not I'll have to put in even more logic to handle this case.. On Fri, Jan 22, 2016 at 9:22 PM, Jack Krupansky wrote: > I recall that there was some

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

I recall that there was some discussion last year about this issue of how risky it is to do an automated CREATE TABLE IF NOT EXISTS due to the unpredictable amount of time it takes for the table creation to fully propagate around the full cluster. I think it was recognized as a real problem, but

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

I sort of agree.. but we are also considering migrating to hourly tables.. and what if the single script doesn't run. I like having N nodes make changes like this because in my experience that central / single box will usually fail at the wrong time :-/ On Fri, Jan 22, 2016 at 6:47 PM,

Re: automated CREATE TABLE just nuked my cluster after a 2.0 -> 2.1 upgrade....

Instead of using ZK, why not solve your concurrency problem by removing it? By that, I mean simply have 1 process that creates all your tables instead of creating a race condition intentionally? On Fri, Jan 22, 2016 at 6:16 PM Kevin Burton wrote: > Not sure if this is a bug