--- title: Configuring missing replication changes description: 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. component: pingdirectory version: 11.0 page_id: pingdirectory:pingdirectory_server_administration_guide:pd_ds_replication_config_missing_changes canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/pingdirectory_server_administration_guide/pd_ds_replication_config_missing_changes.html revdate: December 8, 2023 page_aliases: ["pd_ds_replication_missing_change_types.adoc", "pd_ds_replication_supported_config.adoc"] section_ids: missing-change-types-and-actions: Missing change types and actions missing-change-types: Missing change types missing-change-actions: Missing change actions supported-configurations-and-examples: Supported configurations and examples examples: Examples --- # 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 | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `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. | | `FAVOR_AVAILABILITY` | Provide increased availability when compared to `FAVOR_INTEGRITY` with regard to `PREVIOUS` missing changes. This is the default policy. | | `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: ``` dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization" --set missing-changes-policy:favor-integrity ``` To keep the `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 ```