[ https://issues.apache.org/jira/browse/CASSANDRA-13403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242120#comment-16242120 ]
Ludovic Boutros commented on CASSANDRA-13403: --------------------------------------------- And the if we rebuild the index: {code} INFO [RMI TCP Connection(7)-10.53.0.15] 2017-11-07 15:44:34,456 ColumnFamilyStore.java:806 - User Requested secondary index re-build for lubo_test/t_doc indexes: i_doc DEBUG [RMI TCP Connection(7)-10.53.0.15] 2017-11-07 15:44:34,458 ColumnFamilyStore.java:899 - Enqueuing flush of IndexInfo: 0,385KiB (0%) on-heap, 0,000KiB (0%) off-heap DEBUG [PerDiskMemtableFlushWriter_0:5] 2017-11-07 15:44:34,514 Memtable.java:461 - Writing Memtable-IndexInfo@1020363412(0,049KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit), flushed range = (min(-9223372036854775808), max(9223372036854775807)] DEBUG [PerDiskMemtableFlushWriter_0:5] 2017-11-07 15:44:34,515 Memtable.java:490 - Completed flushing /data/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/mc-18-big-Data.db (0,036KiB) for commitlog position CommitLogPosition(segmentId=1510062526702, position=2214781) DEBUG [MemtableFlushWriter:5] 2017-11-07 15:44:34,644 ColumnFamilyStore.java:1197 - Flushed to [BigTableReader(path='/data/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/mc-18-big-Data.db')] (1 sstables, 4,854KiB), biggest 4,854KiB, smallest 4,854KiB INFO [RMI TCP Connection(7)-10.53.0.15] 2017-11-07 15:44:34,644 SecondaryIndexManager.java:365 - Submitting index build of i_doc for data in BigTableReader(path='/data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-23-big-Data.db'),BigTableReader(path='/data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-22-big-Data.db') INFO [CompactionExecutor:10] 2017-11-07 15:44:34,646 PerSSTableIndexWriter.java:279 - Scheduling index flush to /data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-22-big-SI_i_doc.db INFO [SASI-General:3] 2017-11-07 15:44:34,675 PerSSTableIndexWriter.java:330 - Index flush to /data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-22-big-SI_i_doc.db took 28 ms. {code} {code} INFO [CompactionExecutor:10] 2017-11-07 15:44:34,676 DataTracker.java:152 - SSTableIndex.open(column: r, minTerm: 0, maxTerm: 0, minKey: 1, maxKey: 7, sstable: BigTableReader(path='/data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-22-big-Data.db')) {code} {code} INFO [CompactionExecutor:10] 2017-11-07 15:44:34,677 PerSSTableIndexWriter.java:279 - Scheduling index flush to /data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-23-big-SI_i_doc.db INFO [SASI-General:3] 2017-11-07 15:44:34,683 PerSSTableIndexWriter.java:330 - Index flush to /data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-23-big-SI_i_doc.db took 5 ms. {code} {code} INFO [CompactionExecutor:10] 2017-11-07 15:44:34,683 DataTracker.java:152 - SSTableIndex.open(column: r, minTerm: 0, maxTerm: 0, minKey: 11, maxKey: 9, sstable: BigTableReader(path='/data/cassandra/data/lubo_test/t_doc-64343790c31611e7a46403e2ed27ae86/mc-23-big-Data.db')) {code} {code} INFO [RMI TCP Connection(7)-10.53.0.15] 2017-11-07 15:44:34,683 SecondaryIndexManager.java:385 - Index build of i_doc complete {code} We can see the two lines of log of the DataTracker. > nodetool repair breaks SASI index > --------------------------------- > > Key: CASSANDRA-13403 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13403 > Project: Cassandra > Issue Type: Bug > Components: sasi > Environment: 3.10 > Reporter: Igor Novgorodov > Assignee: Alex Petrov > Attachments: 3_nodes_compaction.log, 4_nodes_compaction.log > > > I've got table: > {code} > CREATE TABLE cservice.bulks_recipients ( > recipient text, > bulk_id uuid, > datetime_final timestamp, > datetime_sent timestamp, > request_id uuid, > status int, > PRIMARY KEY (recipient, bulk_id) > ) WITH CLUSTERING ORDER BY (bulk_id ASC) > AND bloom_filter_fp_chance = 0.01 > AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'} > 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'; > CREATE CUSTOM INDEX bulk_recipients_bulk_id ON cservice.bulks_recipients > (bulk_id) USING 'org.apache.cassandra.index.sasi.SASIIndex'; > {code} > There are 11 rows in it: > {code} > > select * from bulks_recipients; > ... > (11 rows) > {code} > Let's query by index (all rows have the same *bulk_id*): > {code} > > select * from bulks_recipients where bulk_id = > > baa94815-e276-4ca4-adda-5b9734e6c4a5; > > > ... > (11 rows) > {code} > Ok, everything is fine. > Now i'm doing *nodetool repair --partitioner-range --job-threads 4 --full* on > each node in cluster sequentially. > After it finished: > {code} > > select * from bulks_recipients where bulk_id = > > baa94815-e276-4ca4-adda-5b9734e6c4a5; > ... > (2 rows) > {code} > Only two rows. > While the rows are actually there: > {code} > > select * from bulks_recipients; > ... > (11 rows) > {code} > If i issue an incremental repair on a random node, i can get like 7 rows > after index query. > Dropping index and recreating it fixes the issue. Is it a bug or am i doing > the repair the wrong way? -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org