Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Roland Gude <roland.gude@yoochoose.com>
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Date: Mon, 18 Apr 2011 02:15:34 -0700
Subject: AW: Two versions of schema
Thread-Topic: Two versions of schema
Thread-Index: Acv7oB3ZfxiFHMFjQ6uyjxB7ZmJQ1QCBqwsA
Message-ID: 
 <120CB7532EA53A4D8CA6B63F94B4ADB351E6D630C9@IE2RD2XVS021.red002.local>
References: <1302894224705-6277365.post@n2.nabble.com>
In-Reply-To: <1302894224705-6277365.post@n2.nabble.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Schema updates in cassandra tickle through the cluster over time very much =
like normal writes do.
But they keep some state indicating the "parent" schema and they will only =
be applied to some node if the parent schema is correct thus asserting the =
correct order of schema changes. This process is subject to failure for ins=
tance because of nodes being down or network errors. If such a failure happ=
ens there it's still possible that everything is relatively easy fixed. Tak=
e down the node that missed the updates (use drain) and bring it back only.=
 This might work (and does not take that long). If it does not take it down=
 again (again drain) delete the data in the system keyspace. Bring it back =
online.

There is however a situation where you are really screwed. It is when you i=
ssue updates concurrently to different nodes. The schema versions will disa=
gree and there is now possibility to bring them back to the same version ag=
ain. In this case you need to select one node, bring down all nodes that ha=
ve a different schema, delete their system keyspace and bring them back.

Schema changes should not be seen as something that can be done regularly. =
It should not be done programmatically. There should always be some operato=
r looking at the cluster verifying that all nodes are reachable and ring is=
 ok. And then issue schema changes one at a time using the cli.

Greetings,
roland

-----Urspr=FCngliche Nachricht-----
Von: mcasandra [mailto:mohitanchlia@gmail.com]=20
Gesendet: Freitag, 15. April 2011 21:04
An: cassandra-user@incubator.apache.org
Betreff: Two versions of schema

Is there a problem?


[default@StressKeyspace] update column family StressStandard with
keys_cached=3D100;
854ee0a0-6792-11e0-81f9-93d987913479
Waiting for schema agreement...
The schema has not settled in 10 seconds; further migrations are ill-advise=
d
until it does.
Versions are 854ee0a0-6792-11e0-81f9-93d987913479:[10.18.62.202,
10.18.62.203, 10.18.62.200, 10.18.62.204, 10.18.62.199, 10.18.62.196,
10.18.62.197],22d165ff-6783-11e0-81f9-93d987913479:[10.18.62.198]


I remember reading somewhere before that when you have 2 versions of schema=
s
you are basically in trouble. Can someone explain what it means and it's
implications?

--
View this message in context: http://cassandra-user-incubator-apache-org.30=
65146.n2.nabble.com/Two-versions-of-schema-tp6277365p6277365.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at N=
abble.com.