# Static XDR configuration

This page describes how to statically configure Cross Datacenter Replication (XDR).

::: note
Aerospike recommends configuring XDR dynamically so that all nodes start shipping at the same time. See [Dynamic XDR configuration](https://aerospike.com/docs/database/manage/xdr/dynamic-xdr).
:::

## Overview

All XDR-related parameters are included in the Aerospike configuration file, as shown in [Basic static XDR stanza](#the-xdr-stanza).

For an architectural overview, see [XDR Architecture](https://aerospike.com/docs/database/learn/architecture/xdr).

### 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`](https://aerospike.com/docs/database/reference/config#xdr__ship-versions-policy) controls how XDR ships versions of modified records when facing lag between the source cluster and a destination.
-   [`ship-versions-interval`](https://aerospike.com/docs/database/reference/config#xdr__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

Terminal window

```bash
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`](https://aerospike.com/docs/database/reference/config#xdr__dc) | None | Declare a variable name for the datacenter.  
  
The `xdr` stanza can include a maximum of 64 `dc` sub-stanzas.  
  
 |
| [`node-address-port`](https://aerospike.com/docs/database/reference/config#xdr__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](https://aerospike.com/docs/database/manage/xdr/security). |
| [`namespace`](https://aerospike.com/docs/database/reference/config#xdr__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`](https://aerospike.com/docs/database/reference/config#xdr__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`.

Terminal window

```bash
xdr {

  dc DC1 {

    node-address-port 10.0.0.1 3000

    namespace A {

       # Map local namespace A to remote namespace B

       remote-namespace B

    }

  }

}
```

::: note
Prior to Database 8.1.0, the value of `remote-namespace` must be unique across namespaces in the local DC. Two or more namespaces in a cluster cannot map to the same remote namespace, but two different clusters can each map to the same namespace in a third cluster. If multiple namespaces are mapped to same remote namespace with the same set, records with same keys will be overwritten and only the record that arrives last will persist.
:::

See [`remote-namespace`](https://aerospike.com/docs/database/reference/config#xdr__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](https://aerospike.com/docs/database/learn/architecture/xdr). Only the [basic XDR stanzas](https://aerospike.com/docs/database/manage/xdr/static-xdr/#the-xdr-stanza) 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](#tab-panel-912)
-   [Datacenter B at 10.2.0.2](#tab-panel-913)

Terminal window

```bash
xdr {

   dc B {

      node-address-port 10.2.0.2 3000

      namespace someNameSpaceName {

         ...

      }

   }

}
```

Terminal window

```bash
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](#tab-panel-914)
-   [Datacenter B at 10.2.0.2](#tab-panel-915)
-   [Datacenter C at 10.3.0.3](#tab-panel-916)

Terminal window

```bash
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 {

         ...

      }

   }

}
```

Terminal window

```bash
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 {

         ...

      }

   }

}
```

Terminal window

```bash
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`](https://aerospike.com/docs/database/reference/config#xdr__src-id) must be different in all the datacenters.
-   [`conflict-resolve-writes`](https://aerospike.com/docs/database/reference/config#namespace__conflict-resolve-writes) must be set to `true` in the namespace-level in all datacenters.
-   [`bin-policy`](https://aerospike.com/docs/database/reference/config#xdr__bin-policy) must not be `all`.
:::

-   [Datacenter A at 10.0.0.1](#tab-panel-917)
-   [Datacenter B at 10.2.0.2](#tab-panel-918)
-   [Datacenter C at 10.3.0.3](#tab-panel-919)

Terminal window

```bash
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

      }

   }

}
```

Terminal window

```bash
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

      }

   }

}
```

Terminal window

```bash
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](#tab-panel-920)
-   [Datacenter B at 10.2.0.2 ships to C at 10.3.0.3](#tab-panel-921)
-   [Datacenter C at 10.3.0.3](#tab-panel-922)

Terminal window

```bash
xdr {

   dc B {

      node-address-port 10.2.0.2 3000

      namespace someNameSpaceName {

         ...

      }

   }

}
```

Terminal window

```bash
xdr {

   dc C {

      node-address-port 10.3.0.3 3000

      namespace someNameSpaceName {

         forward true

         ...

      }

   }

}
```

```plaintext
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**

Terminal window

```bash
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.
:::

### 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.0:
    -   The XDR subsystem must be configured statically with at least one datacenter. See [Static XDR configuration](https://aerospike.com/docs/database/manage/xdr/static-xdr).
    -   The XDR subsystem did not accept dynamic configuration commands because it was not initialized if XDR was not configured statically.

## More XDR information

-   [Set policy](https://aerospike.com/docs/database/manage/xdr/set-policy)
-   [Bin policy](https://aerospike.com/docs/database/manage/xdr/bin-policy)
-   [Write policy](https://aerospike.com/docs/database/manage/xdr/write-policy)
-   [Bin convergence](https://aerospike.com/docs/database/manage/xdr/convergence)
-   [Filters](https://aerospike.com/docs/database/manage/xdr/filters)
-   [Lifecycle of XDR record shipment with metrics](https://aerospike.com/docs/database/manage/xdr/lifecycle)
-   [Compression, record forwarding, and deleted records](https://aerospike.com/docs/database/manage/xdr/comp-fwd-deletes)
-   [Securing with access control, LDAP, and TLS](https://aerospike.com/docs/database/manage/xdr/security)
-   [Reference XDR parameters and metrics](https://aerospike.com/docs/database/manage/xdr/parameters)