Aerospike is pleased to announce the general availability of Aerospike 5.2.
XDR Enhancements
The Aerospike Cross-Datacenter Replication (XDR) feature asynchronously replicates data between clusters, typically over higher-latency links such as WANs. XDR supports a variety of interconnection topologies, and allows fine-grained control over which namespaces, sets, or bins to ship. Aerospike Database 5 laid the foundation for XDR enhancements, some of which are now being rolled out in 5.2 with additional ones targeted for subsequent releases.
Improved Shipping of Modified Bins
Aerospike 5.2 uses an improved algorithm for shipping modified bins that guarantees that only the exact set of changed bins is shipped in all cases. In Aerospike 4.x releases, XDR used a Bloom filter based implementation for shipping modified bins and this could occasionally cause a small number of unmodified bins to also be shipped along with any modified bins.
Expanded Bin Shipping Policy
Aerospike 5.2 allows bins to be explicitly configured for inclusion during any shipping event whether they have been modified or not. Furthermore, an application can specify a combination of policies to be used as selection criteria, by setting the bin-policy configuration parameter to one of the following values:
Bin Policy | Effect |
ALL (default) | Ship all bins |
ONLY_CHANGED | Ship only bins whose values have changed since the last ship time |
ONLY_SPECIFIED | Ship only specified bins |
CHANGED_AND_SPECIFIED | Ship only specified bins that have changed |
CHANGED_OR_SPECIFIED | Ship specified bins plus any bins that have changed |
Changed bin shipping incurs a cost in storage and memory per-bin, therefore customers should perform before-and-after measurements when deciding to use this feature.
The write-policy configuration parameter determines whether the target DC treats shipped records as updates or replacements. It takes the following values:
Write Policy | Effect |
UPDATE | Record is updated |
REPLACE | Record is replaced |
AUTO (default) | Record is updated if not all the bins were changed or bin-policy includes “CHANGED”; otherwise Replace |
Ship to a Different Namespace
By default, XDR ships records from a source DC namespace to a destination namespace with the same name. Aerospike 5.2 introduces the ability to ship records to a different destination namespace, subject to some restrictions (see the documentation for details). A common use case would be a configuration where records in namespace A on the source DC are shipped to namespace B in the destination DC, where A ≠ B.
XDR Proxy
The XDR Proxy acts as an intermediary for XDR traffic between a source cluster and a destination cluster. This is needed in situations where the IP addresses of the destination nodes are not reachable from the source nodes. An example of this is in Kubernetes-based deployments, where the destination nodes are running in a Virtual Private Cloud isolated from the source nodes. In this context the XDR Proxy acts as a service gateway to the destination nodes. However, XDR Proxies can be used in any context (typically security-related) where source and destination exist in different IP routing domains.
Redesigned Filters
Filtering is a popular task commonly used to select records that satisfy a filter expression specified by the application. Since Aerospike 4.7, filters can be used with all single record operations (reads, writes, and record UDFs), batch reads, scans and secondary index queries. Aerospike 5.2 introduces a new API for filters based on Aerospike Expressions, a functional syntax that is more intuitive and expands the scope of what can be used to select records. In earlier releases until 5.1, predicate filters were based on Reverse Polish Notation (RPN) syntax.The key aspects that differentiate Expressions from the previous RPN based predicate expressions include:
support for all data type operations: the full List and Map APIs (including at a nested element context), bitwise operations on Bytes (BLOBs), Geospatial queries on GeoJSON, and HyperLogLog operations
expanded filtering operations on metadata
a more convenient Polish Notation syntax
As before, the new implementation only reads a record if its data is used by the Expression. Large performance gains can be realized when an Expression filters on record metadata, which is stored in the primary index that is memory-resident.Expressions are incompatible with the existing predicate filter APIs (PredExp), so developers who want to use them will need to upgrade to a newer client version and convert any old predicate expression logic. The Aerospike 5.2 database supports both filter APIs, with the older predicate expressions API being deprecated and planned for removal in a future version of the server. Additional more powerful enhancements to filtering in the future will be based on Expressions.Expressions will be made available to developers shortly after the Aerospike 5.2 release, first in the Java and C# clients, with support for the feature rolling out in other language clients subsequently.
Other Noteworthy Updates
Aerospike 5.2 contains a number of smaller features, a few of which are noteworthy. Refer to the 5.2 release for a complete list of features and upgrade considerations.
stay-quiesced service-context configuration parameter: if true, a node will start up quiesced. Based on the node being a cluster member, this provides a lightweight mechanism for providing a tie-breaker node in the event of a network failure. This is particularly useful in rack-aware configurations where a loss of connectivity might result in a tie-break situation.
ignore-migrate-fill-delay namespace-context configuration parameter: used to exempt specific namespaces from the effects of the global migrate-fill-delay parameter. Useful in cases where the node will be down temporarily (e.g. for an upgrade) but nevertheless contains a few critical namespaces that need to be migrated for the duration.
