Marcus Eriksson created CASSANDRA-18119:
-------------------------------------------
Summary: Handle sstable metadata stats file getting a new mtime
after compaction has finished
Key: CASSANDRA-18119
URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
Due to a race between compaction finishing and compaction strategies getting
reloaded there is a chance that we try to add both the new sstable and the old
compacted sstable to the compaction strategy, and in the LCS case this can
cause the old sstable to get sent to L0 to avoid overlap. This changes the
mtime of the stats metadata file and if the node is shut down before the
sstable is actually deleted from disk, we fail starting with the following
exception:
{code}
.../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
[junit-timeout]
REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
[junit-timeout] ***Unexpected files detected for sstable
[nb-0-big-]: last update time [Thu Dec 15 10:24:09 CET 2022] (1671096249000)
should have been [Thu Dec 15 10:24:07 CET 2022] (1671096247000)
[junit-timeout]
ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
{code}
A workaround for this (until we properly fix the way compaction strategies get
notified about sstable changes) is to ignore the timestamp of the STATS
component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
