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 >