incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Michalski <mich...@opera.com>
Subject Re: Unable to drop secondary index
Date Mon, 27 May 2013 10:02:11 GMT
(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 <michalm@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.
>>
>
>


Mime
View raw message