ScyllaDB Docs ScyllaDB Enterprise Upgrade Guide - ScyllaDB Enterprise 2024.1 to 2024.2

Caution

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

Upgrade Guide - ScyllaDB Enterprise 2024.1 to 2024.2¶

This document is a step by step procedure for upgrading from ScyllaDB Enterprise 2024.1 to ScyllaDB Enterprise 2024.2, and rollback to version 2024.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 driver before 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.

Check Feature Updates

See the ScyllaDB Enterprise Release Notes for the latest updates. The Release Notes are published at the ScyllaDB Community Forum.

Please take special note of the following feature updates in 2024.2:

Raft-based consistent schema management for new and existing deployments is enabled by default and cannot be disabled.
The new Data Distribution with Tablets feature is disabled by default. If you want to use tablets in your existing cluster after upgrading to 2024.2, you need to enable the enable_tablets option in your cluster and create a new keyspace with the tablets = {'enabled': true} option.
The schema of audit.audit_log has been migrated from SimpleStrategy RF=1 to NetworkTopologyStrategy RF=3. By default, every DC will contain 3 audit replicas.
- If you add a new DC, you need to manually alter the audit’s schema if you want that DC also to contain audit replicas.
- CL for writes still equals 1, which may make reading audit rows with CL=Quorum fail (especially in clusters with less than 3 nodes).

Upgrade Procedure¶

Note

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.

A ScyllaDB upgrade is a rolling procedure that does not require full cluster shutdown. For each of the nodes in the cluster, you will:

Check that the cluster’s schema is synchronized.
Backup the data.
Backup the configuration file.
Stop ScyllaDB.
Download and install new ScyllaDB packages.
Start ScyllaDB.
Validate that the upgrade was successful.

During the rolling upgrade, it is highly recommended:

Not to use the new 2024.2 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 may need to verify that Raft has been successfully initiated in your cluster.
You need to enable consistent topology updates.

See After Upgrading Every Node for details.

Upgrade Steps¶

Check the cluster schema¶

Make sure that all nodes have the schema synchronized before the 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 to create backups.

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 scylla --version. You should take note of the current version in case you want to rollback the upgrade.

Update the ScyllaDB deb repo (Debian, Ubuntu) to 2024.2

Configure Java 1.11:

sudo apt-get update
sudo apt-get install -y openjdk-11-jre-headless
sudo update-java-alternatives -s java-1.11.0-openjdk-amd64

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.

Update the ScyllaDB rpm repo to 2024.2.

Install the new ScyllaDB version:

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

If you’re using the ScyllaDB official image (recommended), see the Debian/Ubuntu 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:

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

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
sudo apt-get dist-upgrade scylla-enterprise-machine-image

Run scylla_setup without running io_setup (note that running scylla_setup during the upgrade may trigger resharding).
Run sudo /opt/scylladb/scylla-machine-image/scylla_cloud_io_setup.

Start the node¶

sudo service scylla-server start

Validate¶

Check cluster status with nodetool status and make sure all nodes, including the one you just upgraded, are in UN status.
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.
Check scylla-server log (using journalctl _COMM=scylla) and /var/log/syslog to validate there are no new errors in the log.
Check again after two minutes to validate that no new issues are introduced.

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

After Upgrading Every Node¶

After you have upgraded every node, perform the following procedures.

Validate Raft setup. This step only applies if you manually disabled consistent cluster management with Raft before upgrading to version 2024.1, so the consistent_cluster_management option was set to false in 2024.1.

In ScyllaDB 2024.2, Raft-based consistent schema management for new and existing deployments is enabled by default and cannot be disabled. You need to verify if Raft was successfully initiated in your cluster before you proceed to the next step. See Validate Raft Setup for instructions.
Enable the Raft-based consistent topology updates feature. See Enable Consistent Topology Updates for instructions.

Validate Raft Setup¶

Note

Skip this step if you upgraded to 2024.1 with default settings. This section only applies if you manually disabled the consistent_cluster_management option before upgrading to version 2024.1.

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¶

Warning

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

The following procedure describes a rollback from ScyllaDB Enterprise 2024.2.x to 2024.1.y. Apply this procedure if an upgrade from 2024.1 to 2024.2 fails before completing on all nodes.

Use this procedure only on the nodes you upgraded to 2024.2.
Execute the following commands one node at a time, moving to the next node only after the rollback procedure is completed successfully.

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

Drain the node and stop ScyllaDB
Retrieve the old ScyllaDB packages
Restore the configuration file
Reload systemd configuration
Restart ScyllaDB
Validate the rollback success

Apply the 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¶

Remove the old repo file.

sudo rm -rf /etc/apt/sources.list.d/scylla.list

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

Install:

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

Answer ‘y’ to the first two questions.

Remove the old repo file.

sudo rm -rf /etc/yum.repos.d/scylla.repo

Update the ScyllaDB rpm repo to 2024.1.

Install:

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

Restore the configuration file¶

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