Skip to main content

Change Notification for version 4.9 and earlier

Change notification before Aerospike 5.0

Aerospike versions 4.9 and below used HTTP as a transport mechanism. This has been replaced with the more efficient XDR protocol in 5.0 and above. This document describes that older, HTTP-based, system.

HTTP Protocol

The shipping thread composes an HTTP request and uses the POST method to notify one of the configured HTTP servers. As HTTP is a well established protocol, with a wide variety of HTTP server implementations with different performance levels, users can choose their preferred web server to consume the records.


A serious flaw has been discovered for http v2 in the library used by change notification. http-version MUST be set to v1 to prevent xdr and change notification from being blocked.

Possible impact on performance

Generating HTTP messages within Aerospike has extra cost, compared to generating XDR messages. Use of change notification can increase CPU load on an Aerospike cluster, but the source cluster might or might not require additional server nodes.


As Aerospike is delivering messages through the HTTP protocol, the receiver must emit an OK response when the message is successfully consumed. Aerospike waits for the "OK" response. If the response is not made within a certain time, the HTTP request TCP connection will be broken and the POST request will be made again.

In some cases, this may seem to result in duplicate delivery or out of order delivery. Please be aware of the tradeoffs of responding with OK early, allowing greater throughput, vs responding OK when the message has been reliably ingested and committed to storage.

Example config

Use https in http-url if using tls.

xdr {
enable-xdr true
enable-change-notification true
xdr-digestlog-path /etc/aerospike/digestlog.log1 100G
xdr-compression-threshold 1000
xdr-info-port 3004

datacenter DC1 {
dc-node-address-port 3000

datacenter jetty {
dc-type http
http-version v1

namespace bar {
enable-xdr true
xdr-remote-datacenter DC1
replication-factor 2

namespace test {
enable-xdr true
xdr-remote-datacenter jetty
replication-factor 2
memory-size 4G
default-ttl 30d
storage-engine memory

The following table explains the configuration parameters for change notification.

This table does not list the required, related Cross-Datacenter Replication parameters. Use of these parameters is shown above.

Config NameContextAllowed ValuesDefault ValueDescription
enable-change-notificationxdrtrue, falsefalseStatic config. Enables change notification.
dc-typedatacenteraerospike, httpaerospikeOnly skeleton DC’s type can be changed dynamically to http (from default aerospike)
http-versiondatacenterv1v1Dynamic config. v1 means communicate only in http v1.1. A serious flaw has been discovered for http v2 in the library used by change notification. Prior to 4.8, http-version must be explicitly set to v1 to prevent xdr and change notification from being blocked. The values v2 and v2-prior-knowledge are no longer supported as of version 4.8.
http-urldatacenterNADynamic config. Multiple lines of this config are recommended. Each one specifies an endpoint to which XDR sends data in a load balanced fashion. Example: http://yourServer1:8086/EndPoint1 http://yourServer2:8086/EndPoint2 These values can be set dynamically while the server is running. See the following example. If the URL is prefixed with http://, clear text HTTP is used. If the URL is prefixed with https://, SSL is used
tls-namedatacenterNULLOptional. Applicable to connector true and http. Value is the name of the tls sub-stanza from which to select the CA file or CA file path. For certificate requirements, such as values for the CN, and background details, see tls-name and Authentication. For example aerospike.conf configuration setup, see Configuration Parameters Reference.