Static XDR configuration
This page describes how to statically configure Cross Datacenter Replication (XDR).
Overview
All XDR-related parameters are included in the Aerospike configuration file, as shown in Basic static XDR stanza.
For an architectural overview, see XDR Architecture.
Terminology
- Shipping refers to sending data from one datacenter (DC) to another.
- A cluster from which records are shipped is a source cluster.
- A cluster to which records are shipped is a destination cluster.
Shipping policies
ship-versions-policy
controls how XDR ships versions of modified records when facing lag between the source cluster and a destination.ship-versions-interval
specifies a time window in seconds within which XDR is allowed to skip versions.
The XDR stanza
The xdr
stanza in the configuration file uses xdr
, dc
, node-address-port
, and namespace
to:
- Enable XDR
- Define target datacenters, including IP addresses and ports of cluster nodes
- Specify which namespaces to ship
xdr { dc dataCenter1 { node-address-port someIpAddress1 somePort1 namespace nameSpaceName1A { ... } namespace nameSpaceName1B { // optional - can be all empty bin-policy <all/only-changed/changed-and-specified/...> enable-compression <true/false> forward <true/false> ignore-expunges <true/false> max-throughput 50000 transaction-queue-limit 32768 write-policy <auto/update/replace> remote-namespace <someRemoteNameSpace> ship-only-specified-sets <true/false> // if ship-only-specified-sets set to true ship-set <someSetName1> ship-set <someSetName2> // refer to the configuration reference manual // for the full list of optional parameters ... } } dc dataCenter2 { node-address-port <someIpAddress2> <somePort2> namespace nameSpaceName2A { ... } namespace nameSpaceName2B { ... } } ...}
Parameter description
Parameter | Default value | Description |
---|---|---|
xdr | No value is required. | Enables XDR and encloses all other XDR-related parameters. |
dc | None | Declare a variable name for the datacenter. The xdr stanza can include a maximum of 64 dc sub-stanzas. |
node-address-port | None | Specifies the IP address and port of a node in the remote datacenter. The dc sub-stanza can include multiple node-address-port specifications. Most of these examples show only one node-address-port .The port specification can be followed by a Transport Layer Security (TLS) variable name you define. See Securing XDR with access control, LDAP, and TLS. |
namespace | None | Specifies the name of the namespace data to ship to the remote datacenters. The dc stanza can include multiple namespace declarations. The remote-namespace parameter is required only if the namespace needs to be replicated to a different namespace. |
Global naming convention for namespaces
We recommend that you develop a global plan or naming convention for namespaces on all your clusters that participate in XDR.
Global naming conventions can help clarify the purposes and locations of namespaces, avoid violating naming restrictions which can cause errors, and minimize confusion due to a misunderstanding of, or lack of knowledge of, existing namespaces or namespace mappings.
Namespace mapping
Multiple namespaces in the source cluster can ship to the same remote-namespace
.
xdr { dc DC1 { node-address-port 10.0.0.1 3000 namespace A { # Map local namespace A to remote namespace B remote-namespace B } }}
See remote-namespace
for details.
Example configuration parameters for XDR topologies
This section presents configuration file parameters that correspond to different supported topologies described in XDR Architecture. Only the basic XDR stanzas are shown, with no optional parameters.
Active-passive
In active-passive topology, data are written to only a single node and then shipped to other datacenters.
xdr { dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... } }}
There is no configuration needed on datacenter B.
Mesh (active-active)
In the following examples, each datacenter ships to all the others but not to itself.
xdr { dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... } } dc C { node-address-port 10.3.0.3 3000 namespace someNameSpaceName { ... } }}
xdr { dc A { node-address-port 10.0.0.1 3000 namespace someNameSpaceName { ... } } dc C { node-address-port 10.3.0.3 3000 namespace someNameSpaceName { ... } }}
xdr { dc A { node-address-port 10.0.0.1 3000 namespace someNameSpaceName { ... } } dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... } }}
Mesh with bin-convergence (active-active)
In this example, each datacenter ships to all the others with bin-convergence feature turned on.
namespace { ... conflict-resolve-writes true}
xdr { src-id 1 dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... bin-policy only-changed ship-bin-luts true } } dc C { node-address-port 10.3.0.3 3000 namespace someNameSpaceName { ... bin-policy only-changed ship-bin-luts true } }}
namespace { ... conflict-resolve-writes true}
xdr { src-id 2 dc A { node-address-port 10.0.0.1 3000 namespace someNameSpaceName { ... bin-policy only-changed ship-bin-luts true } } dc C { node-address-port 10.3.0.3 3000 namespace someNameSpaceName { ... bin-policy only-changed ship-bin-luts true } }}
namespace { ... conflict-resolve-writes true}
xdr { src-id 3 dc A { node-address-port 10.0.0.1 3000 namespace someNameSpaceName { ... bin-policy only-changed ship-bin-luts true } } dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... bin-policy only-changed ship-bin-luts true } }}
Linear chain
In linear chain topology, data is shipped in a straight line from one datacenter to another, and another.
In the following example, in Datacenter B, forward true
is needed to ship records from Datacenter B to Datacenter C.
To avoid a loop, Datacenter C must not point back to A.
xdr { dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... } }}
xdr { dc C { node-address-port 10.3.0.3 3000 namespace someNameSpaceName { forward true ... } }}
There is no configuration needed on datacenter C.
Star
In the following example, Datacenter A ships to all other datacenters, with no shipment between those other datacenters.
Datacenter A at 10.0.0.1
xdr { dc B { node-address-port 10.2.0.2 3000 namespace someNameSpaceName { ... } } dc C { node-address-port 10.3.0.3 3000 namespace someNameSpaceName { ... } } dc D { node-address-port 10.4.0.4 3000 namespace someNameSpaceName { ... } } dc E { node-address-port 10.5.0.5 3000 namespace someNameSpaceName { ... } }}
Database version changes
XDR does not impose any version requirement across datacenters, however different versions of Aerospike Database have the following variations.
- Prior to Database 5.7:
- The XDR subsystem must be configured statically with at least one datacenter. See Static XDR configuration.
- The XDR subsystem did not accept dynamic configuration commands because it was not initialized if XDR was not configured statically.