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 Enterprise Upgrade Guide - ScyllaDB Enterprise 2023.1 to 2024.1

Caution

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

Upgrade Guide - ScyllaDB Enterprise 2023.1 to 2024.1¶

This document is a step by step procedure for upgrading from ScyllaDB Enterprise 2023.1 to ScyllaDB Enterprise 2024.1, and rollback to version 2023.1 if required.

This guide covers upgrading ScyllaDB on Red Hat Enterprise Linux (RHEL) CentOS, Debian, and Ubuntu. See OS Support by Platform and Version for information about supported versions.

This guide also applies when you’re upgrading ScyllaDB Enterprise official image on EC2, GCP, or Azure.

Before You Upgrade ScyllaDB Enterprise¶

Upgrade Your Driver

If you’re using a ScyllaDB driver, upgrade the driverbefore you upgrade ScyllaDB Enterprise. The latest two versions of each driver are supported.

Upgrade ScyllaDB Monitoring Stack

If you’re using the ScyllaDB Monitoring Stack, verify that your Monitoring Stack version supports the ScyllaDB Enterprise version to which you want to upgrade. See ScyllaDB Monitoring Stack Support Matrix. We recommend upgrading the Monitoring Stack to the latest version.

Note

DateTieredCompactionStrategy is removed in 2024.1. Migrate to TimeWindowCompactionStrategy before you upgrade from 2023.1 to 2024.1.

Note

In ScyllaDB Enterprise 2024.1, Raft-based consistent cluster management for existing deployments is enabled by default. If you want the consistent cluster management feature to be disabled in version 2024.1, you must update the configuration before upgrading from 2023.1 to 2024.1:

  1. Set consistent_cluster_management: false in the scylla.yaml configuration file on each node in the cluster.

  2. Start the upgrade procedure.

Consistent cluster management cannot be disabled in version 2024.1 if it was enabled in version 2023.1 in one of the following ways:

  • Your cluster was created in version 2023.1 with the default consistent_cluster_management: true configuration in scylla.yaml.

  • You explicitly set consistent_cluster_management: true in scylla.yaml in an existing cluster in version 2023.1.

Upgrade Procedure¶

A ScyllaDB upgrade is a rolling procedure which does not require full cluster shutdown. For each of the nodes in the cluster 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

  • Start ScyllaDB

  • Validate that the upgrade was successful

Caution

Apply the 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 2024.1 features.

  • Not to run administration functions, like repairs, refresh, rebuild or add or remove nodes. See sctool for suspending ScyllaDB Manager’s scheduled or running repairs.

  • Not to apply schema changes.

After the upgrade, you need to verify that Raft was successfully initiated in your cluster. You can skip this step only in one of the following cases:

  • The consistent_cluster_management option was enabled in a previous ScyllaDB version.

  • You you disabled the consistent_cluster_management option before upgrading to version 2024.1, as described in the note in the Before You Upgrade ScyllaDB section.

Otherwise, as soon as every node has been upgraded to the new version, the cluster will start a procedure that initializes the Raft algorithm for consistent cluster metadata management. You must then verify that the Raft initialization procedure has successfully finished.

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

Backup the data¶

Before any major procedure, like an upgrade, it is recommended to backup all the data to an external device. You can use ScyllaDB Manager for creating backups.

Backup the configuration file¶

sudo cp -a /etc/scylla/scylla.yaml /etc/scylla/scylla.yaml.backup-src

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 scylla --version. You should use the same version as this version in case you want to rollback the upgrade. If you are not running a 2023.1.x version, stop right here! This guide only covers 2023.1.x to 2024.1.y upgrades.

To upgrade ScyllaDB Enterprise:

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

  2. Configure Java 1.8:

    sudo apt-get update
    sudo apt-get install -y openjdk-8-jre-headless
    sudo update-java-alternatives -s java-1.8.0-openjdk-amd64
    
  3. Install the new ScyllaDB version:

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

Answer ‘y’ to the first two questions.

Installing the New Version on Cloud

If you’re using the ScyllaDB official image (recommended), see the EC2/GCP/Azure Ubuntu Image tab for upgrade instructions. If you’re using your own image and installed ScyllaDB packages for Ubuntu or Debian, you need to apply an extended upgrade procedure:

  1. Update the ScyllaDB deb repo (see above).

  2. Configure Java 1.8 (see above).

  3. Install the new ScyllaDB version with the additional scylla-enterprise-machine-image package:

    sudo apt-get clean all
    sudo apt-get update
    sudo apt-get dist-upgrade scylla-enterprise
    sudo apt-get dist-upgrade scylla-enterprise-machine-image
    
  4. Run scylla_setup without running io_setup (note that running scylla_setup during the upgrade may trigger resharding).

  5. Run sudo /opt/scylladb/scylla-machine-image/scylla_cloud_io_setup.

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

To upgrade ScyllaDB:

  1. Update the ScyllaDB rpm repo to 2024.1.

  2. Install the new ScyllaDB version:

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

Installing the New Version on Cloud

If you’re using the ScyllaDB official image (recommended), see the EC2/GCP/Azure Ubuntu Image tab for upgrade instructions. If you’re using your own image and installed ScyllaDB packages for CentOS/RHEL, you need to apply an extended upgrade procedure:

  1. Update the ScyllaDB deb repo (see above).

  2. Install the new ScyllaDB version with the additional scylla-enterprise-machine-image package:

    sudo yum clean all
    sudo yum update scylla\* -y
    sudo yum update scylla-enterprise-machine-image
    
  3. Run scylla_setup without running io_setup (note that running scylla_setup during the upgrade may trigger resharding).

  4. Run sudo /opt/scylladb/scylla-machine-image/scylla_cloud_io_setup.

Note

If you are running a ScyllaDB Enterprise official image (for EC2 AMI, GCP, or Azure), you need to download and install the new ScyllaDB Enterprise release for Ubuntu. See Upgrade ScyllaDB Image for more information.

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 (using 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 ScyllaDB Enterprise Metrics Update - ScyllaDB Enterprise 2023.1 to 2024.1 for more information.

After Upgrading Every Node¶

This section applies to upgrades where Raft is initialized for the first time in the cluster, which in 2024.1 happens by default.

You can skip this section only in one of the following cases:

  • The consistent_cluster_management option was enabled in a previous ScyllaDB version (i.e., Raft was enabled in a version prior to 2024.1).

  • You disabled the consistent_cluster_management option before upgrading to 2024.1, as described in the note in the Before You Upgrade ScyllaDB section (i.e., you prevented Raft from being enabled in 2024.1).

Validate Raft Setup¶

Enabling Raft causes the ScyllaDB cluster to start an internal Raft initialization procedure as soon as every node is upgraded to the new version. The goal of that 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 the schema is synchronized on every step), and if there are no problems with cluster connectivity, that internal procedure should take a few seconds to finish. However, the procedure requires full cluster availability. If one of the nodes fails before the procedure finishes (for example, due to a hardware problem), the process may get stuck, which may prevent schema or topology changes in your cluster.

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

Refer to the Verifying that the internal Raft upgrade procedure finished successfully section for instructions on verifying that the procedure was successful and proceeding if it gets stuck.

Rollback Procedure¶

Note

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

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

Warning

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

ScyllaDB rollback is a rolling procedure which does not require a full cluster shutdown. For each of the nodes you rollback to 2023.1 you will:

  • Drain the node and stop ScyllaDB

  • Retrieve the old ScyllaDB packages

  • Restore the configuration file

  • Restore system tables

  • 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
sudo service scylla-server stop

Download and install the old release¶

  1. Remove the old repo file.

    sudo rm -rf /etc/apt/sources.list.d/scylla.list
    
  2. Update the ScyllaDB deb repo (Debian, Ubuntu) to 2023.1.

  3. Install:

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

Answer ‘y’ to the first two questions.

  1. Remove the old repo file.

    sudo rm -rf /etc/yum.repos.d/scylla.repo
    
  2. Update the ScyllaDB rpm repo to 2023.1.

  3. Install:

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

Note

If you are running a ScyllaDB Enterprise official image (for EC2 AMI, GCP, or Azure), follow the instructions for Ubuntu.

Restore the configuration file¶

sudo rm -rf /etc/scylla/scylla.yaml
sudo cp -a /etc/scylla/scylla.yaml.backup-src | /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?

  • Create an issue

On this page

  • Upgrade Guide - ScyllaDB Enterprise 2023.1 to 2024.1
    • Before You Upgrade ScyllaDB Enterprise
    • Upgrade Procedure
    • Upgrade Steps
      • Check the cluster schema
      • Backup the data
      • Backup the configuration file
      • Gracefully stop the node
      • Download and install the new release
      • Start the node
      • Validate
    • After Upgrading Every Node
      • Validate Raft Setup
    • Rollback Procedure
    • Rollback Steps
      • Drain and gracefully stop the node
      • Download and install the old release
      • Restore the configuration file
      • Reload systemd configuration
      • Start the node
      • Validate
ScyllaDB Enterprise
  • enterprise
    • 2024.2
    • 2024.1
    • 2023.1
    • 2022.2
  • Getting Started
    • Install ScyllaDB Enterprise
      • ScyllaDB Web Installer for Linux
      • Install ScyllaDB Without root Privileges
      • Install scylla-jmx Package
      • Air-gapped Server Installation
      • ScyllaDB Housekeeping and how to disable it
      • ScyllaDB Developer Mode
      • Launch ScyllaDB on AWS
      • Launch ScyllaDB on GCP
      • Launch ScyllaDB on Azure
    • Configure ScyllaDB
    • ScyllaDB Configuration Reference
    • ScyllaDB Requirements
      • System Requirements
      • OS Support
      • Cloud Instance Recommendations
      • ScyllaDB in a Shared Environment
    • Migrate to ScyllaDB
      • Migration Process from Cassandra to ScyllaDB
      • ScyllaDB and Apache Cassandra Compatibility
      • Migration Tools Overview
    • Integration Solutions
      • Integrate ScyllaDB with Spark
      • Integrate ScyllaDB with KairosDB
      • Integrate ScyllaDB with Presto
      • Integrate ScyllaDB with Elasticsearch
      • Integrate ScyllaDB with Kubernetes
      • Integrate ScyllaDB with the JanusGraph Graph Data System
      • Integrate ScyllaDB with DataDog
      • Integrate ScyllaDB with Kafka
      • Integrate ScyllaDB with IOTA Chronicle
      • Integrate ScyllaDB with Spring
      • Shard-Aware Kafka Connector for ScyllaDB
      • Install ScyllaDB with Ansible
      • Integrate ScyllaDB with Databricks
      • Integrate ScyllaDB with Jaeger Server
      • Integrate ScyllaDB with MindsDB
    • Tutorials
  • ScyllaDB for Administrators
    • Administration Guide
    • Procedures
      • Cluster Management
      • Backup & Restore
      • Change Configuration
      • Maintenance
      • Best Practices
      • Benchmarking ScyllaDB
      • Migrate from Cassandra to ScyllaDB
      • Disable Housekeeping
    • Security
      • ScyllaDB Security Checklist
      • Enable Authentication
      • Enable and Disable Authentication Without Downtime
      • Creating a Custom Superuser
      • Generate a cqlshrc File
      • Reset Authenticator Password
      • Enable Authorization
      • Grant Authorization CQL Reference
      • Certificate-based Authentication
      • 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
      • Configure SaslauthdAuthenticator
      • Encryption at Rest
      • LDAP Authentication
      • LDAP Authorization (Role Management)
      • Software Bill Of Materials (SBOM)
    • Admin Tools
      • Nodetool Reference
      • CQLSh
      • Admin REST API
      • Tracing
      • ScyllaDB SStable
      • ScyllaDB Types
      • SSTableLoader
      • cassandra-stress
      • SSTabledump
      • SSTableMetadata
      • ScyllaDB Logs
      • Seastar Perftune
      • Virtual Tables
      • Reading mutation fragments
      • Maintenance socket
      • Maintenance mode
      • Task manager
    • Version Support Policy
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
    • ScyllaDB Manager
    • Upgrade Procedures
      • About Upgrade
      • Upgrade Guides
    • System Configuration
      • System Configuration Guide
      • scylla.yaml
      • ScyllaDB Snitches
    • Benchmarking ScyllaDB
    • ScyllaDB Diagnostic Tools
  • ScyllaDB for Developers
    • Develop with ScyllaDB
    • Tutorials and Example Projects
    • Learn to Use ScyllaDB
    • ScyllaDB Alternator
    • ScyllaDB Drivers
      • ScyllaDB CQL Drivers
      • ScyllaDB DynamoDB Drivers
  • CQL Reference
    • CQLSh: the CQL shell
    • Appendices
    • Compaction
    • Consistency Levels
    • Consistency Level Calculator
    • Data Definition
    • Data Manipulation
      • SELECT
      • INSERT
      • UPDATE
      • DELETE
      • BATCH
    • Data Types
    • Definitions
    • Global Secondary Indexes
    • Expiring Data with Time to Live (TTL)
    • Functions
    • Wasm support for user-defined functions
    • JSON Support
    • Materialized Views
    • Non-Reserved CQL Keywords
    • Reserved CQL Keywords
    • DESCRIBE SCHEMA
    • Service Levels
    • ScyllaDB CQL Extensions
  • Features
    • Lightweight Transactions
    • Global Secondary Indexes
    • Local Secondary Indexes
    • Materialized Views
    • Counters
    • Change Data Capture
      • CDC Overview
      • The CDC Log Table
      • Basic operations in CDC
      • CDC Streams
      • CDC Stream Generations
      • Querying CDC Streams
      • Advanced column types
      • Preimages and postimages
      • Data Consistency in CDC
    • Workload Attributes
    • Workload Prioritization
  • ScyllaDB Architecture
    • Data Distribution with Tablets
    • ScyllaDB Ring Architecture
    • ScyllaDB Fault Tolerance
    • Consistency Level Console Demo
    • ScyllaDB Anti-Entropy
      • ScyllaDB Hinted Handoff
      • ScyllaDB Read Repair
      • ScyllaDB Repair
    • SSTable
      • ScyllaDB SSTable - 2.x
      • ScyllaDB SSTable - 3.x
    • Compaction Strategies
    • Raft Consensus Algorithm in ScyllaDB
    • Zero-token Nodes
  • Troubleshooting ScyllaDB
    • Errors and Support
      • Report a ScyllaDB problem
      • Error Messages
      • Change Log Level
    • ScyllaDB Startup
      • Ownership Problems
      • ScyllaDB will not Start
      • ScyllaDB Python Script broken
    • Upgrade
      • Inaccessible configuration files after ScyllaDB upgrade
    • Cluster and Node
      • Handling Node Failures
      • Failure to Add, Remove, or Replace a Node
      • Failed Decommission Problem
      • Cluster Timeouts
      • Node Joined With No Data
      • NullPointerException
      • Failed Schema Sync
    • Data Modeling
      • ScyllaDB Large Partitions Table
      • ScyllaDB Large Rows and Cells Table
      • Large Partitions Hunting
      • Failure to Update the Schema
    • 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
    • ScyllaDB Monitor and Manager
      • Manager and Monitoring integration
      • Manager lists healthy nodes as down
    • Installation and Removal
      • Removing ScyllaDB on Ubuntu breaks system packages
  • Knowledge Base
    • Upgrading from experimental CDC
    • Compaction
    • Consistency in ScyllaDB
    • 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 ScyllaDB and supporting services as a custom user:group
    • Customizing CPUSET
    • Decoding Stack Traces
    • Snapshots and Disk Utilization
    • DPDK mode
    • Debug your database with Flame Graphs
    • Efficient Tombstone Garbage Collection in ICS
    • How to Change gc_grace_seconds for a Table
    • Gossip in ScyllaDB
    • Increase Permission Cache to Avoid Non-paged Queries
    • How does ScyllaDB LWT Differ from Apache Cassandra ?
    • Map CPUs to ScyllaDB Shards
    • ScyllaDB Memory Usage
    • NTP Configuration for ScyllaDB
    • Updating the Mode in perftune.yaml After a ScyllaDB Upgrade
    • POSIX networking for ScyllaDB
    • ScyllaDB consistency quiz for administrators
    • Recreate RAID devices
    • How to Safely Increase the Replication Factor
    • ScyllaDB and Spark integration
    • Increase ScyllaDB resource limits over systemd
    • ScyllaDB Seed Nodes
    • How to Set up a Swap Space
    • ScyllaDB Snapshots
    • ScyllaDB 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
    • ScyllaDB Nodes are Unresponsive
    • Update a Primary Key
    • Using the perf utility with ScyllaDB
    • Configure ScyllaDB Networking with Multiple NIC/IP Combinations
  • Reference
    • AWS Images
    • Azure Images
    • GCP Images
    • Configuration Parameters
    • Glossary
    • Limits
    • ScyllaDB Enterprise vs. Open Source Matrix
    • API Reference (BETA)
    • Metrics (BETA)
  • ScyllaDB University
  • ScyllaDB FAQ
  • Alternator: DynamoDB API in Scylla
    • Getting Started With ScyllaDB Alternator
    • ScyllaDB Alternator for DynamoDB users
    • Alternator-specific APIs
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 09 Apr 2025.
Powered by Sphinx 7.4.7 & ScyllaDB Theme 1.8.6