The ScyllaDB team is pleased to announce the release of ScyllaDB 2026.2.4, a production-ready patch release for ScyllaDB 2026.2 Short Term Support (STS) Minor Feature Release.
More information on ScyllaDB Version Support Policy is available here.
Related Links
Bug Fixes
The following issues are fixed in this release.
Compaction
- Incremental compaction with garbage collection enabled could leave an SSTable on disk that was never registered or deleted. This occurred when the tail of the compacted stream was entirely purgeable. On clusters with tablets enabled, the leaked SSTable could later prevent the node from restarting until the file was manually removed. Garbage-collected SSTables that are not consumed during compaction are now properly marked for deletion at compaction completion, eliminating the leak and the associated risk of data resurrection or failed restarts.
scylladb#31003
Materialized Views (MV)
- Materialized views could contain stale data when garbage collection was enabled with immediate GC mode or repair mode with RF=1. In these cases, deletions from the base table could be discarded during view update processing before being applied to the view, causing the view to miss them. Deletions are now retained during view update processing regardless of the garbage collection timepoint, ensuring view consistency.
scylladb#30964
SSTables
-
A race condition between SSTable metadata rewrites during repair and SSTable relocation by the materialized view subsystem could cause a shard abort with a file-not-found error. This occurred when repairing a base table with materialized views, where the view subsystem could move an SSTable out of the staging directory at the same time its metadata was being rewritten. Metadata rewrites are now properly serialized with SSTable relocations, preventing the conflict.
scylladb#30963 -
A restore operation on tablet-enabled clusters could abort due to a floating-point rounding error in progress tracking. When SSTable batches were divided across tablets, accumulated rounding imprecision could push the progress counter marginally past its expected total, triggering an assertion. Progress tracking now tolerates this rounding error without aborting.
scylladb#30388 -
When rewriting a single SSTable component, the encryption layer now preserves the original encryption parameters from the SSTable’s metadata rather than deriving them from the current schema or node configuration. Previously, if the encryption settings had changed since the SSTable was originally written, the rewritten component could end up with different encryption parameters from the other components, rendering the SSTable unreadable.
scylladb#30995