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 Database 7.1 and later​

Starting with Database 7.1, map key types are strictly enforced to be string, integer, or bytes. Configuration parameters defining the write-block-size and post-write-queue for storage-engine device have been changed.

See the special upgrade process for Aerospike Database 7.1.

Downgrade instructions from Database 7.1 to 7.0​

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

Upgrading to Database 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 Database 7.0.

Downgrade instructions for 7.0​

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

Upgrading to Database 6.4 and later​

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

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

Before upgrading an Aerospike Database 5.x cluster that is serving primary or secondary index queries (scans) to version 6.4 or higher, you must first upgrade to version 6.3, unless you can tolerate queries and scans breaking while the cluster contains a mix of 5.x and 6.4 nodes.

Make sure to also follow other special upgrade instructions, including Storage Format Upgrade in 6.0 Release.

Upgrading to Database 6.3 and later​

Starting in Database 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 Database 6.3.

Upgrading to Database 6.2 and later​

Starting in Database 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 Database 6.1 and later​

Starting in Database 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 Database 6.1.

Downgrade instructions for 6.1 with secondary index in shared memory​

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

Upgrading to Database 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 Database 5.7 and later​

See this advisory about upgrading from Database 5.6 and earlier to Database 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.

Debian/Ubuntu python2 dependency for Database 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.

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

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

Last updated on