[jira] [Commented] (CASSANDRA-11198) Materialized view inconsistency

["Benjamin Roth (JIRA)" <ji...@apache.org>]

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

Benjamin Roth commented on CASSANDRA-11198:
-------------------------------------------

I have a case to reproduce inconsistencies reliably.

I have the following keyspace: https://gist.github.com/brstgt/9e14373a0d9847cde28395d228fc0ce9

Table visits_in is populated with 99 x 99 records of 100 visitors visiting each other except oneself.
So "SELECT count(*) FROM visits_out_mv WHERE user_id_visitor = $x" should always return 99 and "SELECT count(*) FROM visits_in WHERE user_id = $x" also should return 99.

I have a little PHP script to drop + create MVs and check the state:
https://gist.github.com/brstgt/c1ecc4f29e8be10cc1f7917829a75ea8

And this is the output
https://gist.github.com/brstgt/690732a194ba50c0ffaf652f051bce2c
No matter how often I run that script, the output remains similar.

Results:
- View visits_out_mv shows correct result after some time (as expected)
- View visits_out_mv2 NEVER shows correct result, no matter how long I wait
- Apparently there are never any views in build, although the view is obviously not ready (see SELECT count(*) FROM system.views_builds_in_progress)

The tests run on a c* cluster with 3 nodes on 3.0.6 and 3 nodes on 3.0.8.
I observed this bevhaviour also in our production environment with millions of records and hours of waiting for correct results. Even repair on base table does not help.

I hope this is the right ticket for that comment, otherwise let me know :) And let me know if I can help to provide more information

> 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)