(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.




Reply via email to