Configuring missing replication changes

You can configure missing replication changes to prevent server lockdowns that are caused by missing changes. The configuration uses the missing-changes-policy enumeration configuration property.

Configuring missing replication changes makes it easier to:

Recover from difficult cases of missing changes lockdowns.
Configure replication to favor up-time at the expense of data integrity. Missing changes will optionally be ignored and replication will continue.

There can only be one instance of missing-changes-policy per replication server and one instance per replication domain on each replication server.

Missing change types and actions

Missing change types

The missing change types are described in the following table:

Missing change type Description

DIRECT

For server-to-server connections, a contributing replica is found to have missing changes and the missing changes type is not INDIRECT.

This can include replicas that are deleted but not obsolete, as there isn’t sufficient information to determine which server hosted the replica. Also, if the replica has been deleted, it’s unlikely that a server will have more recent changes to fix the missing changes lockdown.

INDIRECT

For server-to-server connections, a contributing replica is found to have missing changes and the replica is:

In the list of replica IDs for the topology
Hosted by a server not involved in the connection

This excludes deleted replicas.

OBSOLETE

The contributing replica with missing changes is obsolete based on the existing definition of obsolete (deleted and all changes older than the purge delay).

This change type is only applicable when the global configuration property replication-purge-obsolete-replicas is set to true, which it is the default setting. This change type takes precedence over the other change types.

PREVIOUS

For local replicas connecting to the replication server, a replica’s backend previously had missing changes. This is indicated by a null change number.

REPLICA

For local replicas connecting to the replication server, a replica is missing changes relative to its local replication server. This can happen when a backend is restored from an older backup.

Missing change actions

The missing change actions are described in the following table:

Missing change action Description

Missing change action	Description
`CONTINUE`	Raise an alert but ignore the missing change and continue. The missing changes will be lost. For the PREVIOUS missing changes type, the persistent missing changes state (null change number) will be permanently cleared.
`PAUSE`	Raise an alert and pause update sending for the particular replica that is missing changes from the source server connected to, but otherwise continue replicating data. The pause will remain in effect until the connection for the replica is restarted.
`SERVER`	Use the value from the corresponding missing changes type configuration property on the replication server.

CONTINUE

Raise an alert but ignore the missing change and continue. The missing changes will be lost. For the PREVIOUS missing changes type, the persistent missing changes state (null change number) will be permanently cleared.

PAUSE

Raise an alert and pause update sending for the particular replica that is missing changes from the source server connected to, but otherwise continue replicating data. The pause will remain in effect until the connection for the replica is restarted.

SERVER

Use the value from the corresponding missing changes type configuration property on the replication server.

Supported configurations and examples

The allowed missing-changes-policy values are described in the following table. Examples of these values used with the dsconfig command are also provided.

Value Description

MAXIMUM_INTEGRITY

Enter the missing changes lockdown state in response to missing changes as much as possible. This strongly favors data integrity over availability.

FAVOR_INTEGRITY

Enter the missing changes lockdown state in response to missing changes where it makes sense for most customers. This balances data integrity and availability and is the default policy.

FAVOR_AVAILABILITY

Provide increased availability when compared to FAVOR_INTEGRITY with regard to PREVIOUS missing changes.

MAXIMUM_AVAILABILITY

Continue in response to missing changes lockdown as much as possible. This strongly favors availability over data integrity.

SERVER

Indicates that the replication server’s configuration should be used. This makes it possible to have one configuration per replication server that can optionally be overridden for each domain.

SERVER is for replication domains only. This is the default value of missing-changes-policy for replication domains.

Examples

For maximum integrity, which was the behavior prior to configurable missing changes, the MAXIMUM_INTEGRITY missing changes policy can be selected for the replication server:

dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization"
--set missing-changes-policy:maximum-integrity

For behavior that is similar to MAXIMUM_INTEGRITY except that missing changes lockdown is avoided for indirect missing changes, the FAVOR_INTEGRITY missing changes policy can be selected for the replication server. This is the default missing changes policy:

dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization"
--set missing-changes-policy:favor-integrity

To keep the default FAVOR_INTEGRITY missing changes policy for all domains except dc=example,dc=com, where MAXIMUM_AVAILABILITY is to be used:

dsconfig set-replication-domain-prop --provider-name "Multimaster Synchronization"
--domain-name dc_example_dc_com --set missing-changes-policy:maximum-availability

PingDirectory