Static XDR configuration

This page describes how to statically configure Aerospike's Cross Datacenter Replication (XDR) service.

Overview

XDR is Aerospike's inter-cluster replication mechanism, and a standard feature in the Aerospike Database Enterprise Edition. When you statically configure XDR, all XDR-related parameters are included in the Aerospike configuration file, as shown in Basic static XDR stanza.

note

• Aerospike recommends configuring XDR dynamically so that all nodes start shipping at the same time. For dynamic configuration instructions, see Dynamic XDR configuration.
• For a theoretical and 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.

Version changes

• XDR does not impose any version requirement across datacenters.
• Starting with Database 7.2, 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.
• Starting with Database 5.7, the XDR subsystem always accepts dynamic configuration commands because it is always initialized even if XDR is not configured statically.
• Prior to Database 5.7, the XDR subsystem must be configured statically with at least one datacenter. For information, see Static XDR configuration.

Basic static XDR stanza

The basic xdr stanza of 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.

If you intend to use namespace mapping, especially take into account the restrictions described in Namespace mapping with remote-namespace.

Global naming conventions can help clarify the purposes and locations of namespaces in your global deployment, avoid violating naming restrictions, and minimize confusion due to a misunderstanding of, or lack of knowledge of, existing namespaces or namespace mappings.

Namespace mapping

In Database 5.2 and later, a namespace can be shipped to a remote namespace with a different name. In earlier versions, the namespace names must match. See remote-namespace for details.

xdr {
  dc DC1 {
    node-address-port 10.0.0.1 3000
    namespace A {
       # Map local namespace A to remote namespace B
       remote-namespace B
    }
  }
}

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.

Datacenter A ships to B at 10.2.0.2

xdr {
   dc B {
      node-address-port 10.2.0.2 3000
      namespace someNameSpaceName {
         ...
      }
   }
}

Datacenter B at 10.2.0.2

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.

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 {
         ...
      }
   }
}

Datacenter B at 10.2.0.2

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 {
         ...
      }
   }
}

Datacenter C at 10.3.0.3

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.

note

• src-id must be different in all the datacenters.
• conflict-resolve-writes must be set to true in the namespace-level in all datacenters.
• bin-policy must not be all.

Datacenter A at 10.0.0.1

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

Datacenter B at 10.2.0.2

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

Datacenter C at 10.3.0.3

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.

Datacenter A at 10.0.0.1 ships to B at 10.2.0.2

xdr {
   dc B {
      node-address-port 10.2.0.2 3000
      namespace someNameSpaceName {
         ...
      }
   }
}

Datacenter B at 10.2.0.2 ships to C at 10.3.0.3

xdr {
   dc C {
      node-address-port 10.3.0.3 3000
      namespace someNameSpaceName {
         forward true
         ...
      }
   }
}

Datacenter C at 10.3.0.3

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 {
         ...
      }
   }
}

note

In the star configuration, there is no configuration needed on datacenters B, C, D, and E.

More XDR information

• Set policy
• Bin policy
• Write policy
• Bin convergence
• Filters
• Lifecycle of XDR record shipment with metrics
• Compression, record forwarding, and deleted records
• Securing with access control, LDAP, and TLS
• Reference XDR parameters and metrics