# Write policy

With the XDR parameter [`write-policy`](https://aerospike.com/docs/database/reference/config#xdr__write-policy) at the datacenter (DC) or namespace level, you can control the behavior of XDR writes on the target DC.

## Values for `write-policy`

-   `auto` (default): Behavior depends on the [`bin-policy`](https://aerospike.com/docs/database/reference/config#xdr__bin-policy) and which bins are updated at the source.
    -   If [`bin-policy`](https://aerospike.com/docs/database/reference/config#xdr__bin-policy) is `all`:
        -   If all bins of the record are shipped, after considering the `ignore-bin` configuration, the remote record is replaced or created.
        -   If a subset of bins is shipped, after considering the `ignore-bin` configuration, the remote record is updated.
    -   If [`bin-policy`](https://aerospike.com/docs/database/reference/config#xdr__bin-policy) is `only-changed`, `changed-and-specified`, or `changed-or-specified`, the remote record is updated.
    -   If [`bin-policy`](https://aerospike.com/docs/database/reference/config#xdr__bin-policy) is `only-specified` _and_ a subset of bins is shipped, the remote record is updated.
-   `update`: creates the record or updates it if it already exists. Merges existing bins with the new bins being written.
-   `replace`: creates the record or replaces it entirely if a previous version of the record already exists. Deletes existing bins for the record.
    -   Not allowed when [`bin-policy`](https://aerospike.com/docs/database/reference/config#xdr__bin-policy) is `only-changed`, `changed-and-specified` or `changed-or-specified`.

### Example

Terminal window

```bash
xdr {

  dc DC1 {

    node-address-port 10.1.0.1 3000

    namespace nameSpaceName {

      write-policy replace

      ...

    }

  }

}
```

## write-policy vs bin-policy vs ignore-bin

The interaction between `write-policy=auto`, `bin-policy`, and `ignore-bin` is complex. The following examples illustrate how bins are shipped and the results at the remote destination in various policy and write scenarios.

::: note
In all example cases:

-   The record on the source datacenter already has bins **b1**, **b2**, and **b3**.
-   `bin-policy` (gray) determines which bins to ship from the source, and `write-policy` (blue) controls the behavior of XDR writes on the remote datacenter.
:::

### Example 1

In the following example, the configuration includes `ignore-bin b3` and **b2** and **b3** are updated on the source.

 ![Bin policy interactions example, case 1](https://aerospike.com/docs/_astro/write-policy1.C2JNVCNK_jcIRr.png)

### Example 2

In the following example, the configuration includes `ignore-bin b4` and **b2** and **b3** are updated on the source.

 ![Bin policy interactions example, case 1](https://aerospike.com/docs/_astro/write-policy2.D6RMYLcO_2w0kxa.png)

### Example 3

In the following example, the configuration includes `ignore-bin b3` and an update comes with bin `b2=NULL` (**b2** gets deleted).

 ![Bin policy interactions example, case 1](https://aerospike.com/docs/_astro/write-policy3.DX_VNjGt_uFg7E.png)

### Example 4

In the following example, the configuration includes `ignore-bin b4`, or `ignore-bin` is not configured, and an update comes with bin `b2=NULL` (**b2** gets deleted).

 ![Bin policy interactions example, case 1](https://aerospike.com/docs/_astro/write-policy4.BfOiw2DG_1RjKFT.png)
::: note
The default `bin-policy` `all` doesn’t maintain a record of changed bins and can only consider the record as it is encountered during processing. Consequently, when using the default `write-policy` `auto`, deleting a bin results in either a replace or update operation, depending on whether all remaining bins are shipped or not. This is why the `ignore-bin` parameter influences the outcome.

When choosing a different `bin-policy`, the last update time (LUT) of each bin is maintained. This allows a bin deletion to be processed as a bin deletion, as opposed to the bin being deleted as a result of the record being replaced with the remaining bins.
:::