Just to know, did you get some errors during the nodetool upgradesstables?
Romain
Le Mardi 2 août 2016 8h40, Julien Anguenot <jul...@anguenot.org> a écrit :
Hey Oskar,
I would comment and add all possible information to that Jira issue…
J.
--Julien Anguenot (@anguenot)
On Aug 2, 2016, at 8:36 AM, Oskar Kjellin <oskar.kjel...@gmail.com> wrote:
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
