[jira] [Comment Edited] (CASSANDRA-11198) Materialized view inconsistency

["Keith Wansbrough (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-11198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424700#comment-15424700 ] 

Keith Wansbrough edited comment on CASSANDRA-11198 at 8/17/16 3:20 PM:
-----------------------------------------------------------------------

I've seen something similar, on 3.0.7.1159. We have a base table scs_subscriber which contains relevant columns ((id), n), phone, revision, and MV table lus_subscriber_phone which contains ((phone), id, n), revision. Rows in scs_subscriber are usually updated by a Paxos batch which does a delete of the whole row followed by an insert, and always have a valid revision. However sometimes when we read a row in lus_subscriber_phone we see revision null rather than the expected value. Successive reads flip intermittently between null and the expected value, even though there is no write activity on the row at the time. Some details in the following gist, including sstabledumps of the base table and two differing replicas of the view.

https://gist.github.com/kw217/bdb92bc5261c3d34aebab59d2eb29f72

The update query we do is roughly

{code}
BEGIN BATCH
DELETE FROM <KEYSPACE>.scs_subscriber WHERE id = ?;
UPDATE <KEYSPACE>.scs_subscriber SET data4 = (?, ?), revision = (?, ?), phone = ?, (and some other fields) WHERE id = ? AND n = 0 IF revision = (?, ?);
APPLY BATCH
{code}



was (Author: kw217):
I've seen something similar, on 3.0.7.1159. We have a base table scs_subscriber which contains relevant columns ((id), n), phone, revision, and MV table lus_subscriber_phone which contains ((phone), id, n), revision. Rows in scs_subscriber are always updated by a Paxos batch which does a delete of the whole row followed by an insert, and always have a valid revision. However sometimes when we read a row in lus_subscriber_phone we see revision null rather than the expected value. Successive reads flip intermittently between null and the expected value, even though there is no write activity on the row at the time. Some details in the following gist, including sstabledumps of the base table and two differing replicas of the view.

https://gist.github.com/kw217/bdb92bc5261c3d34aebab59d2eb29f72

The update query we do is roughly

{code}
BEGIN BATCH
DELETE FROM <KEYSPACE>.scs_subscriber WHERE id = ?;
UPDATE <KEYSPACE>.scs_subscriber SET data4 = (?, ?), revision = (?, ?), phone = ?, (and some other fields) WHERE id = ? AND n = 0 IF revision = (?, ?);
APPLY BATCH
{code}


> Materialized view inconsistency
> -------------------------------
>
>                 Key: CASSANDRA-11198
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11198
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Gábor Auth
>            Assignee: Carl Yeksigian
>         Attachments: CASSANDRA-11198.trace
>
>
> Here is a materialized view:
> {code}
> > DESCRIBE MATERIALIZED VIEW unit_by_transport ;
> CREATE MATERIALIZED VIEW unit_by_transport AS
>     SELECT *
>     FROM unit
>     WHERE transportid IS NOT NULL AND type IS NOT NULL
>     PRIMARY KEY (transportid, id)
>     WITH CLUSTERING ORDER BY (id 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 = 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}
> I cannot reproduce this but sometimes and somehow happened the same issue (https://issues.apache.org/jira/browse/CASSANDRA-10910):
> {code}
> > SELECT transportid, id, type FROM unit_by_transport WHERE transportid=24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 and id=99c05a70-d686-11e5-a169-97287061d5d1;
>  transportid                          | id                                   | type
> --------------------------------------+--------------------------------------+------
>  24f90d20-d61f-11e5-9d3c-8fc3ad6906e2 | 99c05a70-d686-11e5-a169-97287061d5d1 | null
> (1 rows)
> > SELECT transportid, id, type FROM unit WHERE id=99c05a70-d686-11e5-a169-97287061d5d1;
>  transportid | id | type
> -------------+----+------
> (0 rows)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)