[RELEASE] ScyllaDB Manager 3.8.0

Release Notes
, ,
1

The ScyllaDB team announces the release of ScyllaDB Manager 3.8.0, a production-ready minor release of the stable 3.8 branch.

ScyllaDB Manager is a centralized cluster administration and recurrent tasks automation tool.

This release focuses on handling ScyllaDB Manager tasks during cluster topology changes.

Below are the changes in this release.

Dedicated tablet repair task (#4644)

ScyllaDB Manager 3.8.0 introduces new tablet repair task. This lightweight task is resilient to ongoing topology changes and uses ScyllaDB’s 2025.4 incremental repair feature, allowing it to run more frequently with minimal overhead. It can be scheduled with sctool repair tablet command.

New general repair task flags (#4645, #4708)

Apart from the tablet repair task, ScyllaDB Manager 3.8.0 extends general repair task flags with:

  • sctool repair –keyspace-replication - repair keyspaces with specified replication only (all, tablets, or vnodes). When used with other filtering flags (e.g., --keyspace), repaired keyspaces need to match all filtering criteria.
  • sctool repair–allow-empty - by default, scheduling or running a repair that would target no tables ends with an error. This flag allows for scheduling and running such repairs without them.

Recommendations for general and tablet repair tasks

It’s recommended to schedule both tablet and general repair tasks with:

  • sctool repair tablet -c <cluster_ID> --cron <cron_spec>
  • sctool repair -c <cluster_ID> --cron <cron_spec> --keyspace-replication=vnodes --allow-empty

This solution splits a single general repair task into two separate ones, but it also brings additional benefits:

  • Tablet repair task (leveraging incremental repair) can easily be scheduled to run more frequently.
  • Cluster administrators can safely perform cluster topology changes when just the tablet repair task is running.

Note that such a schedule is also recommended for clusters with user data replicated only with tablet or only with vnode keyspaces, since ScyllaDB system keyspaces can be replicated with either of them.

Extended control over cluster suspend and resume (#4647)

The ScyllaDB Manager 3.8.0 release aims to make suspending and resuming the cluster both easier and safer with the following features:

  • sctool suspend --allow-task-type - tasks of this type will keep on being executed and scheduled even when the cluster is suspended.
  • sctool suspend --suspend-policy - describes behavior towards running tasks (other than --allow-task-type). stop_running_tasks results in stopping running tasks. fail_if_running_tasks results in failing to suspend the cluster with appropriate error.
  • sctool suspend --no-continue - indicates that tasks should be started from scratch on a resume. It allows for performing additional cleanup of disabled tasks on suspend (e.g., removing snapshots on nodes’ disks left after interrupted backup).
  • sctool resume --start-tasks-missed-activation - start tasks that missed their activation during suspend.
  • sctool resume --no-continue - tasks started by the resume are started from scratch.

Recommendations for suspending cluster to perform topology changes

ScyllaDB Manager tasks assume stable cluster topology during their execution, with the exception of the new tablet repair task described above. It forces administrators to suspend ScyllaDB Manager tasks for the time of changing cluster topology. Moreover, tasks incompatible with topology changes need to be started from scratch afterwards. Otherwise, unexpected errors may occur.

It’s recommended to suspend the cluster with sctool suspend --allow-task-type=tablet_repair --no-continue and resume it with sctool resume --start-tasks --start-tasks-missed-activation --no-continue. This solution brings the following benefits:

  • Tablet repair task can safely keep on running during topology changes.
  • Snapshots on nodes’ disks are removed so that they no longer cause disk space amplification during topology changes.
  • Not only are the tasks directly interrupted by the suspend, but also the ones which schedule was missed during suspend are started on the resume.
  • Tasks are started from scratch.

In more urgent cases (e.g., cluster resize caused by the need to add more storage), it is advised to use --suspend-policy=stop_running_tasks so that the urgent operation can be performed without delay.

In less urgent cases (e.g., cluster resize caused by too much free storage), it is advised to use fail_if_running_task to make sure that suspend won’t interrupt and lose the progress of currently running tasks.

Cleanup snapshots from interrupted backup (#4648)

As mentioned above, ScyllaDB Manager 3.8.0 automatically removes snapshots from nodes’ disks left by the interrupted backups when --no-continue is used on suspend. Since this is a generally useful feature, it’s also possible to run such cleanup with sctool backup delete local-snapshots command.

Bug fixes and other improvements

  • Fix ScyllaDB Manager Agent choice of pinned CPU (#4627)

  • Use ScyllaDB side default incremental repair mode by default (#4683)

  • Set query idempotency allowing for retries when querying local ScyllaDB Manager database (#4705)

  • Fix filtering of task names containing slashes in sctool (#4653)

Upgrade to the new release

ScyllaDB customers are encouraged to upgrade to ScyllaDB Manager 3.8.0 in coordination with the ScyllaDB support team.

The new release includes upgrades of both ScyllaDB Manager Server and Agent.

Useful Links:

Scylla Manager 3.8.0 supports the following ScyllaDB releases

  • 2025.4
  • 2025.3
  • 2025.2
  • 2025.1
  • 2024.1

You can install and run ScyllaDB Manager on Kubernetes using ScyllaDB Operator. More here.