Standard Database upgrade

Overview

This page describes how to upgrade the Aerospike Database.

By upgrading your Aerospike Database cluster you will gain access to the latest features and bug fixes. The cluster upgrade process involves upgrading one server node at a time, which results in no downtime for the cluster.

Mixed versions

Aerospike supports mixed-version clusters for rolling upgrades. However, Aerospike does not recommend long term use of clusters with nodes running different versions of the Aerospike database.

Caution

Refer to the Special Upgrade instructions page for important information relevant to specific versions.

Download the server package to the node

• Download the Aerospike Database server manually from the Download page.
• It is important to read the release notes of the version you are downloading.
• You can automate downloading versions of the server from the artifact repository. See the FAQ on downloads for details.

Base URL

https://download.aerospike.com/artifacts/aerospike-server-VERSION/SERVER-VERSION/

Download the server package and transfer it to the node. The name of the server package varies by version.

Note

Linux distributions (distros) that use Red Hat packages must use the appropriate Red Hat Enterprise Linux compatible version. See Install on Red Hat Enterprise Linux.

Database 6.2 and later

Note

• Support for ubuntu24.04 LTS was added in Database 7.2.
• Support for Debian 10 ARM64 was removed from Database 6.3.

Starting with Database 6.2 where support for ARM64 is introduced, the server package follows the following naming convention:

aerospike-server-EDITION_VERSION_tools-TOOLS-VERSION_DISTRO_ARCHITECTURE.tgz

edition: community, enterprise, federal

version: 6.2.0.0

distro: debian10, debian11, debian12, ubuntu18.04, ubuntu20.04, ubuntu24.04,el7, el8, el9, amzn2023

architecture: x86_64, aarch64 based on uname -m

Database 6.2 and earlier

In Database 6.2 and earlier, servers were intended to run only on Linux distros and the x86_64 architecture.

aerospike-server-EDITION-VERSION-DISTRO.tgz

edition: community, enterprise, federal

version: 6.1.0.3

distro: debian10, debian11, ubuntu18.04, ubuntu20.04, ubuntu24.04, el7, el8

See Database 6.1.

Stop the Aerospike service

It is a good practice to quiesce a node prior to shutting it down or removing it from a cluster. See the Quiesce Node page for details (Enterprise Edition).

To stop the Aerospike service

# On systemd Linux distros
sudo systemctl stop aerospike

# On System V Linux distros
sudo /etc/init.d/aerospike stop

Caution

If you have namespaces which are configured to be only in-memory with no persistence (storage-engine memory), it is required to wait for migrations to be completed before moving on to the next node to avoid data loss. Refer to Monitoring Migrations.

Unpack the server package

Uncompress the package to get the RPM or Debian packages of the server and tools.

You may need to delete the older version, if upgrading from Aerospike version prior to 3.3.x. To remove the packages look for the old versions of aerospike-VERSION-server and aerospike-VERSION-tools.

# For RRMs
sudo rpm -qa | grep aerospike
sudo rpm -e RPM_NAME

# For Debian packages
sudo dpkg -l | grep aerospike
sudo dpkg -r DPKG_NAME

Install the new packages

Database 6.2 and later

Debian format

aerospike-server-EDITION_VERSION-1DISTRO_ARCHITECTURE.deb
aerospike-tools_VERSION-[commit]DISTRO_ARCHITECTURE.deb

edition: community, enterprise, federal

version: 6.2.0.0

distro: debian10, debian11, ubuntu18.04, ubuntu20.04

architecture: amd64, arm64 based on dpkg-architecture -qDEB_HOST_ARCH

sudo dpkg -i aerospike-server-enterprise_6.2.0.0-1ubuntu20.04_arm64.deb
sudo dpkg -i aerospike-tools_8.1.0-ubuntu20.04_arm64.deb

RPM format

aerospike-server-VERSION-1.RHEL.ARCHITECTURE.rpm
aerospike-tools-VERSION-1.RHEL.ARCHITECTURE.rpm

edition: community, enterprise, federal

version: 6.2.0.0

RHEL: el7, el8

architecture: x86_64, aarch64

sudo rpm -Uvh aerospike-server-enterprise-6.2.0.0-1.el7.aarch64.rpm
sudo rpm -Uvh aerospike-tools-7.4.0-1.el7.aarch64.rpm

Database 6.2 and earlier

Debian format

aerospike-server-VERSION.DISTRO.x86_64.deb
aerospike-tools-VERSION.DISTRO.x86_64.deb

edition: community, enterprise, federal

version: 6.0.0.7, 6.1.0.3, and so on

distro: debian10, debian11, ubuntu18.04, ubuntu20.04

For example

sudo dpkg -i aerospike-server-enterprise-6.0.0.7.ubuntu18.04.x86_64.deb
sudo dpkg -i aerospike-tools-7.3.1.ubuntu18.04.x86_64.deb

RPM format

aerospike-server-VERSION-1.RHEL.x86_64.rpm
aerospike-tools-VERSION-1.RHEL.x86_64.rpm

edition: community, enterprise, federal

version: 6.1.0.3

RHEL: el7, el8

sudo rpm -Uvh aerospike-server-enterprise-6.1.0.3-1.el8.x86_64.rpm
sudo rpm -Uvh aerospike-tools-7.3.1-1.el8.x86_64.rpm

Start the Aerospike service

Restart the server, and wait until the server confirms that the node is ready.

# On systemd Linux distros
sudo systemctl start aerospike

# On System V Linux distros
sudo /etc/init.d/aerospike start

Note

Stopping and starting the Aerospike service makes the node leave the cluster for a short time, which triggers data rebalancing (migrations). The migrate-fill-delay parameter to controls these migrations. Refer to the Delay Migrations page for further details.

Monitor the cluster state

Prior to upgrading another node, verify that the node has re-joined the cluster, by performing these steps:

1. Cluster key is uniform across the cluster, see cluster_key
2. Cluster is of the expected size, see cluster_size

This can be checked through asadm, asinfo or by tailing the logs.

Caution

In some situations, it may require waiting for migrations to complete prior to moving on and stopping the next node.

As of version 4.3, the cluster-stable info command can be used to easily determine whether a cluster is stable.

For versions not supporting the cluster-stable info command, the following conditions would guarantee that migrations have completed following a reclustering event (across all nodes in a cluster):

• migrate_allowed is true
• migrate_partitions_remaining is 0

In order to programmatically check whether the cluster is at a stable state and migrations have finished, the following should be observed:

1. Wait until cluster_key is uniform, the cluster_size is of expected size and migrate_allowed is set to true
2. Wait for migrate_partitions_remaining to be 0
3. Check the cluster_key is still the same as it was in step 1 and that the cluster_size did not change. If these are different, loop over to step 1 and check again.

Situations requiring a wait for migrations between nodes to complete include the following:

• namespaces which are configured to be in-memory only (no persistence, storage-engine memory)
• specific version upgrades requiring persisted data to be deleted (for example version 4.2)
• some use cases for clusters running the older cluster protocol (prior to version 3.13)

On completing the upgrade across all nodes in the cluster, you can confirm from the output of asadm -e "info network" if all the nodes have successfully upgraded to the correct version and that the cluster size is correct. You can look at asadm -e "info node" to check other statistics.

Admin info network
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information (2020-12-16 21:45:32 UTC)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         Node|         Node ID|             IP|    Build|Migrations|~~~~~~~~~~~~~~~~~~Cluster~~~~~~~~~~~~~~~~~~|Client|  Uptime
             |                |               |         |          |Size|         Key|Integrity|      Principal| Conns|
10.0.0.1:3000| BB9010016AE4202|  10.0.0.1:3000|C-5.3.0.1|   0.000  |   5|92DCF600367B|True     |BB9050016AE4202|     2|00:07:48
10.0.0.2:3000| BB9020016AE4202|  10.0.0.2:3000|C-5.3.0.1|   0.000  |   5|92DCF600367B|True     |BB9050016AE4202|     2|00:07:47
10.0.0.3:3000|*BB9030016AE4202|  10.0.0.3:3000|C-5.3.0.1|   0.000  |   5|92DCF600367B|True     |BB9050016AE4202|     2|00:07:46
Number of rows: 5

Note

service ready: soon there will be cake! will be logged after a node is available. The logs can be tailed for “cake” to check for this line:

# On systemd Linux distros
journalctl -u aerospike -a -o cat -f | grep "cake"

# On System V Linux distros
sudo tail -f /var/log/aerospike/aerospike.log | grep "cake"