[RELEASE] ScyllaDB 2026.2.7

Release Notes
, ,
1

The ScyllaDB team is pleased to announce the release of ScyllaDB 2026.2.7, 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

  • A node could get stuck during decommission if a table-wide major compaction was running on a tablet being migrated away: the cleanup step would hang until it eventually timed out, blocking the decommission, with nothing logged to explain the delay. Cleanup now completes reliably in this case.
    scylladb#31238

  • Reads using Time Window Compaction Strategy (TWCS) in reverse order could incorrectly skip some SStables that actually held matching rows, causing those rows to be missing from the query results. This affected only reversed-order reads on TWCS tables. The SStable filtering is now correct, so reversed TWCS reads return complete results.
    scylladb#31248

CQL

  • A PREPARE statement running concurrently with a USE statement on the same connection could race over the connection’s state, which in rare cases corrupted an internal value and caused the node to restart. The connection state is now handled safely so this race can no longer occur.
    scylladb#31346

  • Altering a keyspace to use rack-list replication could hang indefinitely (livelock) when a target rack had no available nodes, for example a node that was stopped and excluded: the request would repeatedly pause and resume without making progress. Such a request now fails immediately with a clear error instead of looping forever.
    scylladb#31150

Logging

  • Session-closing was logged at a high verbosity level left over from an earlier investigation, adding noise to normal operation. The routine session-closing message has now been lowered to a less verbose level, while a warning is still emitted for sessions that stay open for more than 5 minutes.
    scylladb#31362

Raft

  • In rare cases, truncating the Raft log could cause the cluster to lose track of an earlier cluster configuration still present in the log and fall back to an outdated one (for example, a snapshot could be stamped with a stale configuration). This was primarily observed as a rare internal inconsistency in configuration tracking. Configuration tracking now stays consistent after log truncation.
    scylladb#31158

  • Gracefully shutting down a cluster leader node could, in rare cases, leave it still counted as a voter after it had left the cluster. Because the vote count no longer matched the remaining nodes, this could lead to a loss of Raft quorum, which affects topology and schema changes. The departing leader is now correctly excluded, preventing quorum loss during graceful shutdown.
    scylladb#31167

Object Storage

  • A native (object-storage) backup of a table or keyspace could fail if the table or keyspace was dropped after the snapshot was taken but before the upload finished, even though the backup only reads the on-disk snapshot files, which are unaffected by the drop. A backup already in progress now completes successfully even if the source table or keyspace is dropped mid-upload.
    scylladb#31285

  • The first write to a table backed by Google Cloud Storage (GCS) could fail because of an invalid request sent when finalizing an empty upload, which GCS rejects. Because every object-storage SStable begins with an empty marker object, this made GCS-backed keyspaces effectively unusable. Empty uploads are now finalized correctly, so GCS-backed tables work as expected.
    scylladb#31254

Tablets

  • Completing a tablet split could cause a node to restart when the main compaction group involved in the split was non-empty at the time. This case is now handled correctly.
    scylladb#30757

  • After a tablet split, the memory used to index SStables could grow disproportionately (quadratically) as more SStables accumulated, because the two resulting tablet halves were not assigned their correct token ranges. The ranges are now assigned correctly, keeping memory usage proportional to the data stored.
    scylladb#31242