Aerospike is releasing Aerospike Database 7.2, with enhancements to multi-zone deployments through a new active-rack feature and a new version of shipping control for Cross Datacenter Replication (XDR). Version shipping controls provide flexible choices for backups and connectors and will subsequently be leveraged by the Aerospike Backup Service (ABS).
Multi-zone deployments take advantage of Aerospike’s rack awareness, with each availability zone (AZ) being designated a unique rack ID. Prior to Database 7.2, the master and replica partitions could only be evenly distributed across AZs, with each zone receiving an equal share of both. This meant that all AZs in a cross-AZ cluster deployment were active.
With the active-rack configuration parameter introduced by Database 7.2, the operator can designate an AZ as the active zone in the Aerospike cluster, with the other AZs passively receiving synchronous replica writes. In this active-passive cluster deployment, all write operations go to one AZ, avoiding slower cross-AZ acks and reducing egress cost to the minimum.
As a result, this cluster deployment enables AZ fault-tolerant disaster recovery (DR) with the lowest latency profile and lowest cloud provider costs, according to Aerospike.
The new active-rack configuration gives a two-AZ SC deployment the same benefit as a tie-breaker deployment, without needing a third zone, and avoiding operational complications such as a very different config for the active nodes versus the quiesced one, avoiding potential networking issues in the tie-breaker node, and reducing the likelihood of an AZ failure (by having only two).
If the passive AZ goes down, the active AZ (where active-rack is true) continues serving the applications in its AZ with full availability. If the active AZ goes down, a passive AZ can be promoted with a single dynamic configuration change.
XDR is used for the asynchronous delivery of data from an Aerospike source cluster to a variety of destinations.
Database 7.2 introduces a dynamically configurable mechanism to control how XDR ships versions through two new configuration parameters—ship-versions-policy and ship-versions-interval.
The new ship-versions-policy interval ensures that at least one record version will ship per ship-versions-interval in seconds. If the lag between source cluster and destination is such that this cannot be achieved, backpressure will be applied by refusing further writes to the record until its current version has shipped. This interval policy can be used to guarantee a desired update granularity for connectors and backups.
The new ship-versions-policy all is the policy that instructs XDR to confirm that every single version of the record is written to the destinations or else applies backpressure in the form of an XDR hot key error code, refusing the next write until the current version has shipped.
Similarly to the interval policy, in low-throughput use cases, this policy can be used to ensure that the destination (such as another database via Kafka) receives every update to every record. The operator does need to consider the backpressure implications when lag between source and destination increases.
For more details, read the Database 7.2 release notes.
For more information about this release, visit www.aerospike.com.