Hi,

Ran into the same issue when going to 3.5. Completely killed our cluster. Only 
way was to restore a backup.

/Oskar

> On 2 aug. 2016, at 07:54, Julien Anguenot <jul...@anguenot.org> wrote:
> 
> Hey Jesse, 
> 
> You might wanna check and comment against that issue:
> 
>   https://issues.apache.org/jira/browse/CASSANDRA-11887
> 
>   J. 
> 
> --
> Julien Anguenot (@anguenot)
> 
>> On Aug 2, 2016, at 3:16 AM, Jesse Hodges <hodges.je...@gmail.com> wrote:
>> 
>> Hi, I've got a bit of a conundrum. Recently I upgraded from 2.2.3 to 3.7.0 
>> (ddc distribution). Following the upgrade (though this condition may have 
>> existed prior to upgrade)..
>> 
>> I have a table with a simple partition key and multiple clustering keys, and 
>> I have duplicates of many of the primary keys!
>> 
>> I've tried various repair options and lots of searching, but nothing's 
>> really helping. I'm unsure of how to troubleshoot further or potentially 
>> consolidate these keys. This seems like a bug, but hopefully it's something 
>> simple I missed. I'm also willing to troubleshoot further as needed, but I 
>> could use a few getting started pointers.
>> 
>> Example output: primary key is 
>> (partition_id,alarm_id,tenant_id,account_id,source,metric)
>> 
>> 
>> cqlsh:alarms> select * from alarms.last_seen_state  where partition_id=10 
>> and alarm_id='59893';
>> 
>>  partition_id | alarm_id | tenant_id                            | account_id 
>> | source | metric | last_seen                       | value
>> --------------+----------+--------------------------------------+------------+--------+--------+---------------------------------+-------
>>            10 |    59893 | f50f8413-57bb-4eb5-a37c-7482a63ea9a5 |      10303 
>> | PORTAL |    CPU | 2016-08-01 15:27:37.000000+0000 |     1
>>            10 |    59893 | f50f8413-57bb-4eb5-a37c-7482a63ea9a5 |      10303 
>> | PORTAL |    CPU | 2016-08-01 15:07:15.000000+0000 |     1
>> 
>> Thanks, Jesse
> 

Reply via email to