Change Notification for version 4.9 and earlier

Change notification before Aerospike 5.0

Aerospike Database 4.9 used HTTP as a transport mechanism. This was replaced with the more efficient XDR protocol in Database 5.0 and later. This page 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.

caution

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.

Retransmission

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. 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 configuration

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 10.1.2.3 3000
        }

        datacenter jetty {
                dc-type http
                http-version v1
                http-url http://10.0.0.1:8080
                http-url http://10.0.0.2:8080
        }
}

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 Name	Context	Allowed Values	Default Value	Description
enable-change-notification	xdr	true, false	false	Static configuration. Enables change notification.
dc-type	datacenter	aerospike, http	aerospike	Only skeleton DC’s type can be changed dynamically to http (from default aerospike)
http-version	datacenter	v1	v1	Dynamic configuration. v1 means communicate only in http v1.1. A serious flaw has been discovered for http v2 in the library used by change notification.
http-url	datacenter		NA	Dynamic configuration. Multiple lines of this configuration 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 as shown in 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-name	datacenter		NULL	Optional. 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.