Strong-consistency namespace compatibility during Aerospike 6.x to 7.x rolling upgrade

Strong-consistency namespace compatibility during Aerospike 6.x to 7.x rolling upgrade

The goal is to keep a strong-consistency namespace available and linearly consistent while upgrading nodes one at a time from Aerospike 6.x to 7.x. Strong consistency guarantees linearizable single-record writes, but Aerospike has no multi-record transaction rollback, so committed records in a partially failed batch stay visible. Namespaces are schema-less and bins appear implicitly, so there is no ALTER TABLE to reverse.

Rolling upgrades allow mixed major versions only within a limited window, and writing new metadata formats can make a downgrade to the older major version unsupported. It is unclear whether strong-consistency namespaces can be upgraded node by node without a namespace restart, or how clients should treat bins written by the newer version during the mixed-version window. Target patch versions and the upgrade compatibility matrix must be confirmed before planning the change.

Can a strong-consistency namespace stay online during a mixed-version 6.x to 7.x upgrade? What happens to single-record writes acknowledged by a 7.x node if the cluster must revert to 6.x? Which bin visibility rules apply to older clients while versions are mixed?