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.

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

        datacenter aerospike-kafka-source {
                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 aerospike-kafka-source
        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 config. 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 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-url	datacenter		NA	Dynamic 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.com:8086/EndPoint1 http://yourServer2.com: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-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.