Skip to main content
Loading

Special Upgrades

Refer to the Aerospike Database release notes.

Following is the list of different server versions requiring special instructions for upgrading.

Upgrading to server 7.0 and later

The in-memory namespace storage engine has been rewritten, unifying its storage format with the one previously used by storage-engine device and storage-engine pmem. Configuration parameters defining the stop-writes and eviction thresholds for all types of namespace storage engines have been changed.

See the special upgrade process for Aerospike server 7.0.

Downgrade instructions for 7.0

If you must downgrade from a deployment of server 7.0 see Downgrade from Aerospike Database 7.0.

Upgrading to server 6.4 and later

Support for single-bin namespaces is removed from server 6.4. If you do not have single-bin namespaces in your cluster, you can upgrade to server 6.4 with a regular rolling upgrade.

If you use single-bin namespaces, follow the special upgrade process for Aerospike server 6.4.

Upgrading to server 6.3 and later

Starting in server 6.3, four existing server features are gated by new feature-keys. Make sure to download your newly reissued feature-key file, which explicitly includes your entitled server features.

See Special upgrade instructions for Aerospike Server 6.3.

Upgrading to server 6.2 and later

Starting in server 6.2, the package naming convention changed for the server and tools packages. See how to download the server package to the node for details.

Aerospike software (server, tools, C client, and so on) now comes in two formats - 64-bit ARM (aarch64) and 64-bit Intel/AMD (x86_64).

See Upgrading Aerospike.

Upgrading to server 6.1 and later

Starting in server 6.1, secondary index (sindex) names are limited to 64 characters - down from 256. The server does not create any sindex that exceeds the limit, and logs a warning. Before you upgrade, find any secondary index names that exceed the new 64 character limit, delete them, then recreate the sindex with a shorter name.

See Special upgrade instructions for Aerospike Server 6.1.

Downgrade instructions for 6.1 with secondary index in shared memory

If you must downgrade from a deployment of server 6.1 that has a secondary index stored in shared memory, see Downgrade from Aerospike Database 6.1 to 6.0.

Upgrading to server 6.0 and later

When upgrading from version 5.x or 4.9, each persisted namespace storage device, with the exception of PMem backed namespaces, must be erased and its Aerospike device header wiped (zeroized).

See Storage Format Upgrade in 6.0 Release.

Upgrading from Aerospike Database Enterprise Edition to the FIPS 140-2 compliant Federal Edition also requires a few additional steps.

Upgrading to server 5.7 and later

See this advisory about upgrading from server 5.6 and earlier to server 5.7 and later.

Upgrading to version 5.6 and later while using XDR Proxy connector

If using the aerospike XDR Proxy connector, upgrade the XDR Proxy to version 1.1.0 or later before upgrading the Aerospike Database to version 5.6 and later.

Downgrade from version 5.5 or newer to version 5.4 or version 5.3 or version 5.2 (where XDR bin convergence has been used)

See this advisory.

Downgrade from version 5.4 to version 5.3 or version 5.2 (where XDR bin convergence has been used)

See this advisory.

Upgrading from 5.0 or 5.1 to 5.3 or newer - if using the XDR bin projection functionality (via the ship-only-specified-bins configuration parameter).

See this advisory.

Downgrade from version 5.2 or newer (where XDR bin shipping has been used)

See this advisory.

Debian/Ubuntu python2 dependency for server 5.1 and 5.2

Debian/Ubuntu users - if python2 is not installed, see the Python Package Dependency for .deb Installers article.

Upgrading to version 5.0

  • Version 5.0 is a major release with improvements primarily for Cross-Datacenter Replication (XDR).
  • Version 5.0 requires that you first upgrade to version 4.9.
  • Version 5.0 requires that you remove some outdated parameters from your configuration file, or the database will not start.
  • See the upgrade notes for version 5.0.

Upgrading to 4.9.0.7 or newer - Avoiding partition ownership disagreement that prevents migrations from completing

When upgrading to 4.9.0.7+, it is possible though unlikely that upgraded nodes disagree slightly with older nodes about partition ownership. (Older nodes may have been calculating an incorrect, slightly inaccurate uniform balance.) This would result in warnings logged and migrations not finishing. If you observe this, you may work around it by either (a) setting 'prefer-uniform-balance' false until the cluster is upgraded, then resetting 'prefer-uniform-balance' to true, or (b) if you do not need to wait for migrations to complete between node upgrades, simply keep going and upgrade all nodes, after which they will all agree and migrations will finish.

Downgrading from version 4.9 to version 4.8

See this advisory.

Upgrade all clusters to server 4.9 when XDR records with compression enabled won't ship from server 4.8. or later to server 4.3.1 or earlier.

See Upgrade 4.3.x to 4.9 - Avoid compression errors with 4.8.x