--- title: "Standard Database upgrade" description: "Guide for performing a rolling upgrade of Aerospike Database nodes to ensure zero cluster downtime." --- # Standard Database upgrade > For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt) > > All documentation pages available in markdown. Keep your Aerospike Database cluster current by performing a rolling upgrade. This standard process updates one node at a time, ensuring access to the latest features and bug fixes with zero cluster downtime. See [Special upgrades and downgrades](https://aerospike.com/docs/database/8.1.2/advanced/special-upgrades) for upgrade information relevant to specific versions. ::: mixed versions Aerospike supports mixed-version clusters for rolling upgrades. However, we do not recommend long term use of clusters with nodes running different versions of the Aerospike database. ::: ## Best practices for rolling upgrades - For a smooth rolling upgrade with minimal client impact, follow the planned maintenance procedure for your namespace type. These procedures cover quiescing each node before shutting it down, configuring [`migrate-fill-delay`](https://aerospike.com/docs/database/reference/config#service__migrate-fill-delay), and handling host reboots: - **AP namespaces:** [AP planned maintenance procedure](https://aerospike.com/docs/database/8.1.2/manage/cluster/quiesce-node#planned-maintenance) - **SC namespaces:** [SC planned maintenance procedure](https://aerospike.com/docs/database/8.1.2/manage/cluster/consistency#planned-maintenance) (if [`strong-consistency`](https://aerospike.com/docs/database/reference/config#namespace__strong-consistency) is enabled) ## Download the server package - Manually download the server package from the [Aerospike Downloads](https://aerospike.com/download) page. - Read the [release notes](https://aerospike.com/docs/database/release) for the version you are downloading. - You can automate server version downloads from the artifact repository. See the [FAQ on downloads](https://aerospike.com/docs/database/reference/faq#download) 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 that use Red Hat packages must use the appropriate Red Hat Enterprise Linux compatible version. See [Install Aerospike on Linux](https://aerospike.com/docs/database/8.1.2/install/linux). ::: Aerospike Community, Enterprise, and Federal edition [downloads](https://download.aerospike.com/artifacts) are available for all supported Linux distributions, and use the following naming convention: `aerospike-server-EDITION_VERSION_tools-TOOLS-VERSION_DISTRO_ARCHITECTURE.tgz` See the [Linux artifact policy](https://aerospike.com/docs/database/reference/platform-support/#linux-artifact-policy) to learn which Linux versions and distributions support your Aerospike release. ## Stop the Aerospike service Stop the Aerospike service as follows: Terminal window ```bash # On systemd Linux distributions sudo systemctl stop aerospike ``` Terminal window ```bash # On System V Linux distributions sudo /etc/init.d/aerospike stop ``` ::: caution On Aerospike Community Edition, or Enterprise Edition prior to Database 7.0.0, in-memory namespaces without persistence ([`storage-engine memory`](https://aerospike.com/docs/database/reference/config#namespace__storage-engine)) store data in volatile process memory. You must wait for migrations to complete before continuing to the next node to prevent data loss. Starting with Database 7.0.0 EE, in-memory data is stored in [shared memory](https://aerospike.com/docs/database/8.1.2/manage/namespace/storage/config) and survives `asd` restarts, so this does not apply to a rolling upgrade on those versions. See [Monitoring migrations](https://aerospike.com/docs/database/8.1.2/manage/cluster/migrations#monitoring-migrations) for more information. ::: ## Extract the server and tools package To extract the contents of the package, run the following: Terminal window ```bash tar -xvf aerospike.tgz ``` You may need to delete the older release of Aerospike if you upgrade from a release prior to 3.3.y.z. To remove the packages, search for the old releases of `aerospike-VERSION-server` and `aerospike-VERSION-tools`. **For RPMs:** Terminal window ```bash sudo rpm -qa | grep aerospike sudo rpm -e RPM_NAME ``` **For Debian packages:** Terminal window ```bash sudo dpkg -l | grep aerospike sudo dpkg -r DPKG_NAME ``` ## Install the new packages See the [Linux artifact policy](https://aerospike.com/docs/database/reference/platform-support/#linux-artifact-policy) to learn which Linux versions and distributions support your Aerospike release. #### Debian format Terminal window ```bash sudo dpkg -i aerospike-server-enterprise_8.1.0.0-1ubuntu22.04_arm64.deb sudo dpkg -i aerospike-tools_12.0.1-ubuntu22.04_arm64.deb ``` #### RPM format Terminal window ```bash sudo rpm -Uvh aerospike-server-enterprise-8.1.0.0-1.el9.aarch64.rpm sudo rpm -Uvh aerospike-tools-12.0.1-1.el9.aarch64.rpm ``` ## Start the Aerospike service Restart the server, and wait until the server confirms that the node is ready. Terminal window ```bash # On systemd Linux distributions sudo systemctl start aerospike ``` Terminal window ```bash # On System V Linux distributions 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 controls these migrations. See the [Delay Migrations page](https://aerospike.com/docs/database/8.1.2/manage/cluster/delay-migrations) for further details. ::: ## Monitor the cluster state Prior to upgrading another node, verify that the node has re-joined the cluster by checking the following items: - The cluster key is uniform across the cluster, see [`cluster_key`](https://aerospike.com/docs/database/reference/metrics#node_stats__cluster_key). - The cluster is the expected size, see [`cluster_size`](https://aerospike.com/docs/database/reference/metrics#node_stats__cluster_size). This can be checked through [asadm](https://aerospike.com/docs/database/tools/asadm), [asinfo](https://aerospike.com/docs/database/tools/asinfo) or by tailing the logs. ::: caution Some scenarios may require that you wait for migrations to complete prior to moving on and stopping the next node. These scenarios include the following: - in-memory namespaces without persistence (`storage-engine memory`) - specific version upgrades that require persisted data to be deleted (for example, version 4.2.0) - some use cases for clusters running the older cluster protocol (prior to version 3.13) As of version 4.3.0, the [`cluster-stable`](https://aerospike.com/docs/database/reference/info#cluster-stable) info command can be used to easily determine whether a cluster is stable. For versions not supporting the [`cluster-stable`](https://aerospike.com/docs/database/reference/info#cluster-stable) info command, the following conditions would guarantee that migrations have finished following a reclustering event across all nodes in a cluster: - [`migrate_allowed`](https://aerospike.com/docs/database/reference/metrics#node_stats__migrate_allowed) is `true` - [`migrate_partitions_remaining`](https://aerospike.com/docs/database/reference/metrics#node_stats__migrate_partitions_remaining) is `0` To programmatically check whether the cluster is stable and migrations have finished, the following should be observed: - Wait until [`cluster_key`](https://aerospike.com/docs/database/reference/metrics#node_stats__cluster_key) is uniform, the [`cluster_size`](https://aerospike.com/docs/database/reference/metrics#node_stats__cluster_size) is of expected size and [`migrate_allowed`](https://aerospike.com/docs/database/reference/metrics#node_stats__migrate_allowed) is set to `true` - Wait for [`migrate_partitions_remaining`](https://aerospike.com/docs/database/reference/metrics#node_stats__migrate_partitions_remaining) to be `0` - Check the [`cluster_key`](https://aerospike.com/docs/database/reference/metrics#node_stats__cluster_key) is still the same as it was in step 1 and that the [`cluster_size`](https://aerospike.com/docs/database/reference/metrics#node_stats__cluster_size) did not change. If these are different, loop over to step 1 and check again. ::: After completing the upgrade across all nodes in the cluster, run `asadm -e "info network"` to verify that 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. ```plaintext 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!` is logged after a node is available. You can tail the logs and grep for “cake” to check for this line: Terminal window ```bash # On systemd Linux distributions journalctl -u aerospike -a -o cat -f | grep "cake" ``` Terminal window ```bash # On System V Linux distributions sudo tail -f /var/log/aerospike/aerospike.log | grep "cake" ``` :::