XDR is a core feature of Aerospike Enterprise Edition. It asynchronously replicates cluster data over higher-latency links, typically WANs. XDR requires you to provide IPs and ports of all Aerospike nodes of the destination cluster. This may raise security concerns depending on your topology. Accessing remote clusters safely can especially be difficult when working with Kubernetes applications.
The XDR-Proxy addresses these cloud networking issues where the source Aerospike cluster cannot get direct access to the nodes of the remote cluster when it is a different zone or region. This allows two Aerospike clusters, deployed in different regions, to send XDR traffic to each other via one endpoint in each region. It handles addressing of the nodes within each cluster transparently.
It receives data from the Aerospike server via the XDR framework and writes to the destination via the Java Client. Each message contains either an updated/inserted record or a record deletion notification. Each update/insert message contains the full database record including all or a subset of the record's bins. Record deletion notifications contain the namespace and the record digest but not the record bins.
There might be instances where records are re-ordered on the network or across connector instances, in which case a message for an older version of a record could be delivered after a message for a newer version of the same record.
See XDR Proxy Record Ordering Architecture in order to maintain record ordering.
XDR-Proxy behind the Load Balancer
XDR-Proxy without the Load BalancerInstall XDR-Proxy