Write policy

With the XDR parameter 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 and which bins are updated at the source.
  • If 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 is only-changed, changed-and-specified, or changed-or-specified, the remote record is updated.
  • If 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 is only-changed, changed-and-specified or changed-or-specified.

Example

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.

Example 2

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

Example 3

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

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).

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.