(REMINDER: the problem is that I cannot run ALTER on any CF - it seems
to work [schema number changes, no error occurs etc.], but no params are
updated.)
Hi Aaron (let me turn directly to you, as you were the only one who
replied my previous mails ;-) ),
Today we've added new CF and I noticed that I can run a successfull
ALTER on it. I dug a bit and what I found out is that all the "old" /
"broken" CFs have "id" set to an integer (> 1000) in
system.schema_columnfamilies, while the new CF has id = null instead. I
checked other cluster where problem does not exist too and it's the same
- all CFs have id = null.
The question is - can it potentially be a problem? What is (was?) this
"id" used for? Does setting it manually to null via cqlsh sounds like a
very risky thing? ;-)
M.
W dniu 21.04.2013 22:17, aaron morton pisze:
[default@production] describe Users;
show schema; is the cli equivalent of describe in cqlsh.
There was a schema related issue in 1.1 CASSANDRA-4561 that was fixed.
This is a tricky one to diagnose remotely. I could try using nodetool
resetlocalschema on each node, it's just wild guess incase there is something
odd one one node.
Otherwise can you run the migration with DEBUG logging enabled ? This is a prod
system so it may be easier to set DEBUG on
org.apache.cassandra.service.MigrationManager
org.apache.cassandra.db.MigrationRequestVerbHandler
Cheers
-----------------
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 20/04/2013, at 1:42 AM, Michal Michalski <mich...@opera.com> wrote:
It seems we can't update schemas at all. I tried to change read_repair_chance
and it looks the same. However, in this case I'm 99% sure that some of the CFs
I tried to update were NOT updated using CQL *ever* - only CLI. Not good...
But, as I mentioned before - we did the same on test cluster (probably with even
more CLI & CQL mixing) and it works there.
M.
W dniu 19.04.2013 11:03, Michal Michalski pisze:
Hi Aaron,
Was the schema created with CQL or the CLI ?
It was created using Pycassa and - as far as I know - it was managed
only by CLI.
(It's not a good idea to manage one with the other)
Yes, I know - I only tried using CQL after I realized that CLI is not
working, as I had to make it work (which didn't happen, though ;-) )
because my secondary index was returning wrong results and I wasn't able
to rebuild it.
However, I can't tell for sure that no-one else has ever modified it
using CQL before.
Can you provide the schema after the update and the update cf statement?
Update CF statement? I'm not updating it, I'm just trying to drop the
index using DROP statement:
cli: DROP INDEX ON Users.username;
cqlsh: DROP INDEX Users_username_idx;
No other updates have been made.
Here's the Users CF schema printed by CLI:
[default@production] describe Users;
ColumnFamily: Users
Key Validation Class:
org.apache.cassandra.db.marshal.LexicalUUIDType
Default column value validator:
org.apache.cassandra.db.marshal.UTF8Type
Columns sorted by: org.apache.cassandra.db.marshal.AsciiType
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 1.0
DC Local Read repair chance: 0.0
Replicate on write: true
Caching: KEYS_ONLY
Bloom Filter FP chance: default
Built indexes: [Users.Users_active_idx, Users.Users_email_idx,
Users.Users_username_idx]
Column Metadata:
Column Name: date_created
Validation Class: org.apache.cassandra.db.marshal.LongType
Column Name: active
Validation Class: org.apache.cassandra.db.marshal.IntegerType
Index Name: Users_active_idx
Index Type: KEYS
Column Name: email
Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Index Name: Users_email_idx
Index Type: KEYS
Column Name: username
Validation Class: org.apache.cassandra.db.marshal.UTF8Type
Index Name: Users_username_idx
Index Type: KEYS
Column Name: default_account_id
Validation Class:
org.apache.cassandra.db.marshal.LexicalUUIDType
Compaction Strategy:
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy
Compression Options:
sstable_compression:
org.apache.cassandra.io.compress.SnappyCompressor
CQL says (and shows a notification):
/usr/lib/pymodules/python2.7/cqlshlib/cql3handling.py:1519:
UnexpectedTableStructure: Unexpected table structure; may not translate
correctly to CQL. Compact storage CF Users has no column aliases, but
comparator is not UTF8Type.
CREATE TABLE "Users" (
key 'org.apache.cassandra.db.marshal.LexicalUUIDType' PRIMARY KEY,
active varint,
date_created bigint,
default_account_id 'org.apache.cassandra.db.marshal.LexicalUUIDType',
email text,
username text
) WITH COMPACT STORAGE AND
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.000000 AND
gc_grace_seconds=864000 AND
read_repair_chance=1.000000 AND
replicate_on_write='true' AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'SnappyCompressor'};
CREATE INDEX Users_active_idx ON "Users" (active);
CREATE INDEX Users_email_idx ON "Users" (email);
CREATE INDEX Users_username_idx ON "Users" (username);
M.
