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