ScyllaDB University LIVE, FREE Virtual Training Event | March 21
Register for Free
ScyllaDB Documentation Logo Documentation
  • Server
  • Cloud
  • Tools
    • ScyllaDB Manager
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
  • Drivers
    • CQL Drivers
    • DynamoDB Drivers
  • Resources
    • ScyllaDB University
    • Community Forum
    • Tutorials
Download
ScyllaDB Docs ScyllaDB Open Source ScyllaDB for Administrators Upgrade ScyllaDB Upgrade ScyllaDB Open Source Upgrade Guide - ScyllaDB 5.1 to 5.2 Upgrade Guide - ScyllaDB 5.1 to 5.2

Caution

You're viewing documentation for a previous version. Switch to the latest stable version.

Upgrade Guide - ScyllaDB 5.1 to 5.2¶

This document is a step by step procedure for upgrading from ScyllaDB 5.1 to ScyllaDB 5.2, and rollback to version 5.1 if required.

This guide covers upgrading Scylla on Red Hat Enterprise Linux (RHEL) 7/8, CentOS 7/8, Debian 10 and Ubuntu 20.04. It also applies when using ScyllaDB official image on EC2, GCP, or Azure; the image is based on Ubuntu 20.04.

See OS Support by Platform and Version for information about supported versions.

Upgrade Procedure¶

A ScyllaDB upgrade is a rolling procedure which does not require full cluster shutdown. For each of the nodes in the cluster, serially (i.e. one node at a time), you will:

  • Check that the cluster’s schema is synchronized

  • Drain the node and backup the data

  • Backup the configuration file

  • Stop ScyllaDB

  • Download and install new ScyllaDB packages

  • (Optional) Enable consistent cluster management in the configuration file

  • Start ScyllaDB

  • Validate that the upgrade was successful

Apply the following procedure serially on each node. Do not move to the next node before validating that the node you upgraded is up and running the new version.

During the rolling upgrade, it is highly recommended:

  • Not to use the new 5.2 features

  • Not to run administration functions, like repairs, refresh, rebuild or add or remove nodes. See sctool for suspending ScyllaDB Manager (only available for ScyllaDB Enterprise) scheduled or running repairs.

  • Not to apply schema changes

If you enabled consistent cluster management in each node’s configuration file, then as soon as every node has been upgraded to the new version, the cluster will start a procedure which initializes the Raft algorithm for consistent cluster metadata management. You must then verify that this procedure successfully finishes.

Note

If you use the ScyllaDB Monitoring Stack, we recommend upgrading the Monitoring Stack to the latest version before upgrading ScyllaDB.

For ScyllaDB 5.2, you MUST upgrade the Monitoring Stack to version 4.3 or later.

Upgrade Steps¶

Check the cluster schema¶

Make sure that all nodes have the schema synchronized before upgrade. The upgrade procedure will fail if there is a schema disagreement between nodes.

nodetool describecluster

Drain the nodes and backup the data¶

Before any major procedure, like an upgrade, it is recommended to backup all the data to an external device. In Scylla, backup is done using the nodetool snapshot command. For each node in the cluster, run the following command:

nodetool drain
nodetool snapshot

Take note of the directory name that nodetool gives you, and copy all the directories having that name under /var/lib/scylla to a backup device.

When the upgrade is completed on all nodes, remove the snapshot with the nodetool clearsnapshot -t <snapshot> command to prevent running out of space.

Backup the configuration file¶

Back up the scylla.yaml configuration file and the ScyllaDB packages in case you need to rollback the upgrade.

sudo cp -a /etc/scylla/scylla.yaml /etc/scylla/scylla.yaml.backup
sudo cp /etc/apt/sources.list.d/scylla.list ~/scylla.list-backup
sudo cp -a /etc/scylla/scylla.yaml /etc/scylla/scylla.yaml.backup
sudo cp /etc/yum.repos.d/scylla.repo ~/scylla.repo-backup

Gracefully stop the node¶

sudo service scylla-server stop

Download and install the new release¶

Before upgrading, check what version you are running now using dpkg -s scylla-server. You should use the same version as this version in case you want to rollback the upgrade. If you are not running a 5.1.x version, stop right here! This guide only covers 5.1.x to 5.2.y upgrades.

To upgrade ScyllaDB:

  1. Update the ScyllaDB deb repo (Debian, Ubuntu) to 5.2.

  2. Install the new ScyllaDB version:

    sudo apt-get clean all
    sudo apt-get update
    sudo apt-get dist-upgrade scylla
    

Answer ‘y’ to the first two questions.

Before upgrading, check what version you are running now using rpm -qa | grep scylla-server. You should use the same version as this version in case you want to rollback the upgrade. If you are not running a 5.1.x version, stop right here! This guide only covers 5.1.x to 5.2.y upgrades.

To upgrade ScyllaDB:

  1. Update the ScyllaDB rpm repo to 5.2.

  2. Install the new ScyllaDB version:

    sudo yum clean all
    sudo yum update scylla\* -y
    

Note

If you are running a ScyllaDB official image (for EC2 AMI, GCP, or Azure), you need to:

  • Download and install the new ScyllaDB release for Ubuntu; see the Debian/Ubuntu tab above for instructions.

  • Update underlying OS packages.

See Upgrade ScyllaDB Image for details.

(Optional) Enable consistent cluster management in the node’s configuration file¶

If you enable this option on every node, this will cause the Scylla cluster to enable Raft and use it to consistently manage cluster-wide metadata as soon as you finish upgrading every node to the new version. Check the Raft in ScyllaDB document to learn more.

In 5.2, Raft-based consistent cluster management is disabled by default. In 5.3 it will be enabled by default, but you’ll be able to disable it explicitly during upgrade if needed (assuming you haven’t previously enabled it on every node). In further versions the option will be removed and consistent cluster management will be enabled unconditionally.

The option can also be enabled after the cluster is upgraded to 5.2 (see Enabling Raft in existing cluster).

To enable the option, modify the scylla.yaml configuration file in /etc/scylla/ and add the following:

consistent_cluster_management: true

Note

Once you finish upgrading every node with consistent_cluster_management enabled, it won’t be possible to turn the option back off.

Start the node¶

sudo service scylla-server start

Validate¶

  1. Check cluster status with nodetool status and make sure all nodes, including the one you just upgraded, are in UN status.

  2. Use curl -X GET "http://localhost:10000/storage_service/scylla_release_version" to check the ScyllaDB version. Validate that the version matches the one you upgraded to.

  3. Check scylla-server log (by journalctl _COMM=scylla) and /var/log/syslog to validate there are no new errors in the log.

  4. Check again after two minutes, to validate no new issues are introduced.

Once you are sure the node upgrade was successful, move to the next node in the cluster.

See Scylla Metrics Update - Scylla 5.1 to 5.2 for more information..

After upgrading every node¶

The following section applies only if you enabled the consistent_cluster_management option on every node when upgrading the cluster.

Validate Raft setup¶

Enabling consistent_cluster_management on every node during upgrade will cause the Scylla cluster to start an additional internal procedure as soon as every node is upgraded to the new version. The goal of this procedure is to initialize data structures used by the Raft algorithm to consistently manage cluster-wide metadata such as table schemas.

Assuming you performed the rolling upgrade procedure correctly, in particular ensuring that schema is synchronized on every step, and if there are no problems with cluster connectivity, then this follow-up internal procedure should take no longer than a few seconds to finish. However, the procedure requires full cluster availability. If an unlucky accident (e.g. a hardware problem) causes one of your nodes to fail before this procedure finishes, the procedure may get stuck. This may cause the cluster to end up in a state where schema change operations are unavailable.

Therefore, following the rolling upgrade, you must verify that this internal procedure has finished successfully by checking the logs of every Scylla node. If the procedure gets stuck, manual intervention is required.

Refer to the following document for instructions on how to verify that the procedure was successful and how to proceed if it gets stuck: Verifying that the internal Raft upgrade procedure finished successfully.

Rollback Procedure¶

Note

Execute the following commands one node at the time, moving to the next node only after the rollback procedure completed successfully.

The following procedure describes a rollback from ScyllaDB 5.2.x to 5.1.y. Apply this procedure if an upgrade from 5.1 to 5.2 failed before completing on all nodes. Use this procedure only for nodes you upgraded to 5.2.

Warning

The rollback procedure can be applied only if some nodes have not been upgraded to 5.2 yet. As soon as the last node in the rolling upgrade procedure is started with 5.2, rollback becomes impossible. At that point, the only way to restore a cluster to 5.1 is by restoring it from backup.

ScyllaDB rollback is a rolling procedure which does not require full cluster shutdown. For each of the nodes you rollback to 5.1, serially (i.e. one node at a time), you will:

  • Drain the node and stop Scylla

  • Retrieve the old ScyllaDB packages

  • Restore the configuration file

  • Reload systemd configuration

  • Restart ScyllaDB

  • Validate the rollback success

Apply the following procedure serially on each node. Do not move to the next node before validating that the rollback was successful and the node is up and running the old version.

Rollback Steps¶

Drain and gracefully stop the node¶

nodetool drain
nodetool snapshot
sudo service scylla-server stop

Restore and install the old release¶

  1. Restore the 5.1 packages backed up during the upgrade.

    sudo cp ~/scylla.list-backup /etc/apt/sources.list.d/scylla.list
    sudo chown root.root /etc/apt/sources.list.d/scylla.list
    sudo chmod 644 /etc/apt/sources.list.d/scylla.list
    
  2. Install:

    sudo apt-get update
    sudo apt-get remove scylla\* -y
    sudo apt-get install scylla
    

Answer ‘y’ to the first two questions.

  1. Restore the 5.1 packages backed up during the upgrade.

    sudo cp ~/scylla.repo-backup /etc/yum.repos.d/scylla.repo
    sudo chown root.root /etc/yum.repos.d/scylla.repo
    sudo chmod 644 /etc/yum.repos.d/scylla.repo
    
  2. Install:

    sudo yum clean all
    sudo rm -rf /var/cache/yum
    sudo yum downgrade scylla-\*cqlsh -y
    sudo yum remove scylla-\*cqlsh -y
    sudo yum downgrade scylla\* -y
    sudo yum install scylla -y
    

Restore the configuration file¶

sudo rm -rf /etc/scylla/scylla.yaml
sudo cp /etc/scylla/scylla.yaml-backup /etc/scylla/scylla.yaml

Reload systemd configuration¶

You must reload the unit file if the systemd unit file is changed.

sudo systemctl daemon-reload

Start the node¶

sudo service scylla-server start

Validate¶

Check the upgrade instructions above for validation. Once you are sure the node rollback is successful, move to the next node in the cluster.

Was this page helpful?

PREVIOUS
Upgrade Guide - ScyllaDB 5.1 to 5.2
NEXT
ScyllaDB Metric Update - Scylla 5.1 to 5.2
  • Create an issue
  • Edit this page

On this page

  • Upgrade Guide - ScyllaDB 5.1 to 5.2
    • Upgrade Procedure
    • Upgrade Steps
      • Check the cluster schema
      • Drain the nodes and backup the data
      • Backup the configuration file
      • Gracefully stop the node
      • Download and install the new release
      • (Optional) Enable consistent cluster management in the node’s configuration file
      • Start the node
      • Validate
    • After upgrading every node
      • Validate Raft setup
    • Rollback Procedure
    • Rollback Steps
      • Drain and gracefully stop the node
      • Restore and install the old release
      • Restore the configuration file
      • Reload systemd configuration
      • Start the node
      • Validate
ScyllaDB Open Source
  • 5.2
    • master
    • 6.2
    • 6.1
    • 6.0
    • 5.4
    • 5.2
    • 5.1
  • Getting Started
    • Install ScyllaDB
      • ScyllaDB Web Installer for Linux
      • ScyllaDB Unified Installer (relocatable executable)
      • Air-gapped Server Installation
      • What is in each RPM
      • ScyllaDB Housekeeping and how to disable it
      • ScyllaDB Developer Mode
      • ScyllaDB Configuration Reference
    • Configure ScyllaDB
    • ScyllaDB Requirements
      • System Requirements
      • OS Support by Linux Distributions and Version
      • ScyllaDB in a Shared Environment
    • Migrate to ScyllaDB
      • Migration Process from Cassandra to Scylla
      • Scylla and Apache Cassandra Compatibility
      • Migration Tools Overview
    • Integration Solutions
      • Integrate Scylla with Spark
      • Integrate Scylla with KairosDB
      • Integrate Scylla with Presto
      • Integrate Scylla with Elasticsearch
      • Integrate Scylla with Kubernetes
      • Integrate Scylla with the JanusGraph Graph Data System
      • Integrate Scylla with DataDog
      • Integrate Scylla with Kafka
      • Integrate Scylla with IOTA Chronicle
      • Integrate Scylla with Spring
      • Shard-Aware Kafka Connector for Scylla
      • Install Scylla with Ansible
      • Integrate Scylla with Databricks
    • Tutorials
  • ScyllaDB for Administrators
    • Administration Guide
    • Procedures
      • Cluster Management
      • Backup & Restore
      • Change Configuration
      • Maintenance
      • Best Practices
      • Benchmarking Scylla
      • Migrate from Cassandra to Scylla
      • Disable Housekeeping
    • Security
      • ScyllaDB Security Checklist
      • Enable Authentication
      • Enable and Disable Authentication Without Downtime
      • Generate a cqlshrc File
      • Reset Authenticator Password
      • Enable Authorization
      • Grant Authorization CQL Reference
      • Role Based Access Control (RBAC)
      • ScyllaDB Auditing Guide
      • Encryption: Data in Transit Client to Node
      • Encryption: Data in Transit Node to Node
      • Generating a self-signed Certificate Chain Using openssl
      • Encryption at Rest
      • LDAP Authentication
      • LDAP Authorization (Role Management)
    • Admin Tools
      • Nodetool Reference
      • CQLSh
      • REST
      • Tracing
      • Scylla SStable
      • Scylla Types
      • SSTableLoader
      • cassandra-stress
      • SSTabledump
      • SSTable2json
      • Scylla Logs
      • Seastar Perftune
      • Virtual Tables
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
    • ScyllaDB Manager
    • Upgrade Procedures
      • ScyllaDB Open Source Upgrade
      • ScyllaDB Open Source to ScyllaDB Enterprise Upgrade
      • ScyllaDB Image
      • ScyllaDB Enterprise
    • System Configuration
      • System Configuration Guide
      • scylla.yaml
      • ScyllaDB Snitches
    • Benchmarking ScyllaDB
  • ScyllaDB for Developers
    • Learn To Use ScyllaDB
      • Scylla University
      • Course catalog
      • Scylla Essentials
      • Basic Data Modeling
      • Advanced Data Modeling
      • MMS - Learn by Example
      • Care-Pet an IoT Use Case and Example
    • Scylla Alternator
    • Scylla Features
      • Scylla Open Source Features
      • Scylla Enterprise Features
    • Scylla Drivers
      • Scylla CQL Drivers
      • Scylla DynamoDB Drivers
    • Workload Attributes
  • CQL Reference
    • CQLSh: the CQL shell
    • Appendices
    • Compaction
    • Consistency Levels
    • Consistency Level Calculator
    • Data Definition
    • Data Manipulation
    • Data Types
    • Definitions
    • Global Secondary Indexes
    • Additional Information
    • Expiring Data with Time to Live (TTL)
    • Additional Information
    • Functions
    • JSON Support
    • Materialized Views
    • Non-Reserved CQL Keywords
    • Reserved CQL Keywords
    • ScyllaDB CQL Extensions
  • ScyllaDB Architecture
    • ScyllaDB Ring Architecture
    • ScyllaDB Fault Tolerance
    • Consistency Level Console Demo
    • ScyllaDB Anti-Entropy
      • Scylla Hinted Handoff
      • Scylla Read Repair
      • Scylla Repair
    • SSTable
      • ScyllaDB SSTable - 2.x
      • ScyllaDB SSTable - 3.x
    • Compaction Strategies
    • Raft Consensus Algorithm in ScyllaDB
  • Troubleshooting ScyllaDB
    • Errors and Support
      • Report a Scylla problem
      • Error Messages
      • Change Log Level
    • ScyllaDB Startup
      • Ownership Problems
      • Scylla will not Start
      • Scylla Python Script broken
    • Upgrade
      • Inaccessible configuration files after ScyllaDB upgrade
    • Cluster and Node
      • Failed Decommission Problem
      • Cluster Timeouts
      • Node Joined With No Data
      • SocketTimeoutException
      • NullPointerException
    • Data Modeling
      • Scylla Large Partitions Table
      • Scylla Large Rows and Cells Table
      • Large Partitions Hunting
    • Data Storage and SSTables
      • Space Utilization Increasing
      • Disk Space is not Reclaimed
      • SSTable Corruption Problem
      • Pointless Compactions
      • Limiting Compaction
    • CQL
      • Time Range Query Fails
      • COPY FROM Fails
      • CQL Connection Table
      • Reverse queries fail
    • ScyllaDB Monitor and Manager
      • Manager and Monitoring integration
      • Manager lists healthy nodes as down
  • Knowledge Base
    • Upgrading from experimental CDC
    • Compaction
    • Counting all rows in a table is slow
    • CQL Query Does Not Display Entire Result Set
    • When CQLSh query returns partial results with followed by “More”
    • Run Scylla and supporting services as a custom user:group
    • Decoding Stack Traces
    • Snapshots and Disk Utilization
    • DPDK mode
    • Debug your database with Flame Graphs
    • How to Change gc_grace_seconds for a Table
    • Gossip in Scylla
    • Increase Permission Cache to Avoid Non-paged Queries
    • How does Scylla LWT Differ from Apache Cassandra ?
    • Map CPUs to Scylla Shards
    • Scylla Memory Usage
    • NTP Configuration for Scylla
    • Updating the Mode in perftune.yaml After a ScyllaDB Upgrade
    • POSIX networking for Scylla
    • Scylla consistency quiz for administrators
    • Recreate RAID devices
    • How to Safely Increase the Replication Factor
    • Scylla and Spark integration
    • Increase Scylla resource limits over systemd
    • Scylla Seed Nodes
    • How to Set up a Swap Space
    • Scylla Snapshots
    • Scylla payload sent duplicated static columns
    • Stopping a local repair
    • System Limits
    • How to flush old tombstones from a table
    • Time to Live (TTL) and Compaction
    • Scylla Nodes are Unresponsive
    • Update a Primary Key
    • Using the perf utility with Scylla
    • Configure Scylla Networking with Multiple NIC/IP Combinations
  • ScyllaDB FAQ
  • Contribute to ScyllaDB
  • Glossary
  • Alternator: DynamoDB API in Scylla
    • Getting Started With ScyllaDB Alternator
    • ScyllaDB Alternator for DynamoDB users
Docs Tutorials University Contact Us About Us
© 2025, ScyllaDB. All rights reserved. | Terms of Service | Privacy Policy | ScyllaDB, and ScyllaDB Cloud, are registered trademarks of ScyllaDB, Inc.
Last updated on 13 May 2025.
Powered by Sphinx 7.4.7 & ScyllaDB Theme 1.8.6