[
https://issues.apache.org/jira/browse/CASSANDRA-11887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404484#comment-15404484
]
Jesse Hodges commented on CASSANDRA-11887:
------------------------------------------
I encountered this or something very similar on my upgraded from 2.2.3 -> 3.7.0
(ddc distribution)
I'd also point out that a new row that was inserted matching the existing row
keys did not update either row, but added a new one (which is correctly matched
by subsequent inserts)
Current state:
{code}
cqlsh:alarms> desc TABLE last_seen_state ;
CREATE TABLE alarms.last_seen_state (
partition_id int,
alarm_id text,
tenant_id uuid,
account_id text,
source text,
metric text,
last_seen timestamp,
value double,
PRIMARY KEY (partition_id, alarm_id, tenant_id, account_id, source, metric)
) WITH CLUSTERING ORDER BY (alarm_id ASC, tenant_id ASC, account_id ASC, source
ASC, metric ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 262800
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
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-02 17:58:47.000000+0000 | 0.946767
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
(3 rows)
{code}
but this was the output of the same query yesterday:
{code}
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
{code}
> Duplicate rows after a 2.2.5 to 3.0.4 migration
> -----------------------------------------------
>
> Key: CASSANDRA-11887
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11887
> Project: Cassandra
> Issue Type: Bug
> Reporter: Julien Anguenot
> Priority: Blocker
> Fix For: 3.0.x
>
>
> After migrating from 2.2.5 to 3.0.4, some tables seem to carry duplicate
> primary keys.
> Below an example. Note, repair / scrub of such table do not seem to fix nor
> indicate any issues.
> *Table definition*:
> {code}
> CREATE TABLE core.edge_ipsec_vpn_service (
> edge_uuid text PRIMARY KEY,
> enabled boolean,
> endpoints set<frozen<edge_ipsec_vpn_endpoint>>,
> tunnels set<frozen<edge_ipsec_vpn_tunnel>>
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> *UDTs:*
> {code}
> CREATE TYPE core.edge_ipsec_vpn_endpoint (
> network text,
> public_ip text
> );
> CREATE TYPE core.edge_ipsec_vpn_tunnel (
> name text,
> description text,
> peer_ip_address text,
> peer_id text,
> local_ip_address text,
> local_id text,
> local_subnets frozen<set<frozen<edge_ipsec_vpn_subnet>>>,
> peer_subnets frozen<set<frozen<edge_ipsec_vpn_subnet>>>,
> shared_secret text,
> shared_secret_encrypted boolean,
> encryption_protocol text,
> mtu int,
> enabled boolean,
> operational boolean,
> error_details text,
> vpn_peer frozen<edge_ipsec_vpn_peer>
> );
> CREATE TYPE core.edge_ipsec_vpn_subnet (
> name text,
> gateway text,
> netmask text
> );
> CREATE TYPE core.edge_ipsec_vpn_peer (
> type text,
> id text,
> name text,
> vcd_url text,
> vcd_org text,
> vcd_username text
> );
> {code}
> sstabledump extract (IP addressees hidden as well as secrets)
> {code}
> [...]
> {
> "partition" : {
> "key" : [ "84d567cc-0165-4e64-ab97-3a9d06370ba9" ],
> "position" : 131146
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 131236,
> "liveness_info" : { "tstamp" : "2016-05-06T17:07:15.416003Z" },
> "cells" : [
> { "name" : "enabled", "value" : "true" },
> { "name" : "tunnels", "path" : [
> “XXX::1.2.3.4:1.2.3.4:1.2.3.4:1.2.3.4:XXX:XXX:false:AES256:1500:true:false::third
> party\\:1.2.3.4\\:\\:\\:\\:” ], "value" : "" }
> ]
> },
> {
> "type" : "row",
> "position" : 131597,
> "cells" : [
> { "name" : "endpoints", "path" : [ “XXX” ], "value" : "", "tstamp"
> : "2016-03-29T08:05:38.297015Z" },
> { "name" : "tunnels", "path" : [
> “XXX::1.2.3.4:1.2.3.4:1.2.3.4:1.2.3.4:XXX:XXX:false:AES256:1500:true:true::third
> party\\:1.2.3.4\\:\\:\\:\\:” ], "value" : "", "tstamp" :
> "2016-03-29T08:05:38.297015Z" },
> { "name" : "tunnels", "path" : [
> “XXX::1.2.3.4:1.2.3.4:1.2.3.4:1.2.3.4:XXX:XXX:false:AES256:1500:true:false::third
> party\\:1.2.3.4\\:\\:\\:\\:" ], "value" : "", "tstamp" :
> "2016-03-14T18:05:07.262001Z" },
> { "name" : "tunnels", "path" : [
> “XXX::1.2.3.4:1.2.3.4:1.2.3.4:1.2.3.4XXX:XXX:false:AES256:1500:true:true::third
> party\\:1.2.3.4\\:\\:\\:\\:" ], "value" : "", "tstamp" :
> "2016-03-29T08:05:38.297015Z" }
> ]
> },
> {
> "type" : "row",
> "position" : 133644,
> "cells" : [
> { "name" : "tunnels", "path" : [
> “XXX::1.2.3.4:1.2.3.4:1.2.3.4:1.2.3.4:XXX:XXX:false:AES256:1500:true:true::third
> party\\:1.2.3.4\\:\\:\\:\\:" ], "value" : "", "tstamp" :
> "2016-03-29T07:05:27.213013Z" },
> { "name" : "tunnels", "path" : [
> “XXX::1.2.3.4.7:1.2.3.4:1.2.3.4:1.2.3.4:XXX:XXX:false:AES256:1500:true:true::third
> party\\:1.2.3.4\\:\\:\\:\\:" ], "value" : "", "tstamp" :
> "2016-03-29T07:05:27.213013Z" }
> ]
> }
> ]
> },
> [...]
> [...]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)