Skip to main content
Aerospike Vector is now live with LangChain integrationTell me more
Loading

Change Notification for version 4.9 and earlier

Change notification before Aerospike 5.0​

Aerospike versions 4.9 and earlier used HTTP as a transport mechanism. This has been replaced with the more efficient XDR protocol in 5.0 and above. This page describes the 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.

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 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-versiondatacenterv1, v2v1Dynamic config. v1 means communicate only in http v1.1.
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.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-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.
Last updated on