Skip to main content

Upgrading Aerospike

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.

note

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

You can download the Aerospike Database server manually from the Download page. Make sure to read the release notes of the version you are downloading. Alternatively, 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-<edition>/<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 RedHat packages must use the appropriate RedHat Enterprise Linux compatible version. For example, users of Amazon Linux 2, use el7.

Server version 6.2 and newer

Starting with server version 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, and so on

distro: debian10, debian11, ubuntu18.04, ubuntu20.04, el7, el8, and so on

architecture: x86_64, aarch64 based on uname -m

Prior to server version 6.2

Prior to version 6.2, Aerospike Database servers were all 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, and so on

distro: debian10, debian11, ubuntu18.04, ubuntu20.04, el7, el8, and so on

See server version 6.1.

Stop the Aerospike service

note

It is a good practice to quiesce a node prior to shutting it down or removing it from a cluster. Refer to 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-<edition>-server and aerospike-<edition>-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

Server version 6.2 and later

Debian Format

aerospike-server-<edition>_<version>-1<distro>_<architecture>.deb
aerospike-tools_<version>-<[commit]distro>_<architecture>.deb

edition: community, enterprise, federal

version: 6.2.0.0, and so on

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.0.1-ubuntu20.04_arm64.deb

RPM Format

aerospike-server-<edition>-<version>-1.<RHEL>.<architecture>.rpm
aerospike-tools-<version>-1.<RHEL>.<architecture>.rpm

edition: community, enterprise, federal

version: 6.2.0.0, and so on

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

Prior to server version 6.2

Debian Format

aerospike-server-<edition>-<version>.<distro>.x86_64.deb
aerospike-tools-<edition>-<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-<edition>-<version>-1.<RHEL>.x86_64.rpm
aerospike-tools-<version>-1.<RHEL>.x86_64.rpm

edition: community, enterprise, federal

version: 6.1.0.3, and so on

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):

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. Should these be 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 once 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"