--- title: Replication conflicts description: This section provides in-depth information about the mechanisms and possible scenarios behind replication conflicts. component: pingdirectory version: 11.0 page_id: pingdirectory:pingdirectory_server_administration_guide:pd_ds_replication_conflicts canonical_url: https://docs.pingidentity.com/pingdirectory/11.0/pingdirectory_server_administration_guide/pd_ds_replication_conflicts.html revdate: August 1, 2024 page_aliases: ["pd_ds_types_of_replication_conflicts.adoc", "pd_ds_naming_conflict_scenarios.adoc", "pd_ds_modification_conflict_scenarios.adoc"] section_ids: types-of-replication-conflicts: Types of replication conflicts naming-conflict-scenarios: Naming conflict scenarios modification-conflict-scenarios: Modification conflict scenarios --- # Replication conflicts This section provides in-depth information about the mechanisms and possible scenarios behind replication conflicts. Updates to the PingDirectory server entries in a replication topology can happen independently because replication guarantees only eventual consistency and not strong consistency. The eventual consistency model enables applying conflicting changes at different PingDirectory server instances. In most cases, the PingDirectory server can resolve these conflicts automatically and in a consistent manner: for example, all server instances in a replication topology resolving each and every conflict the same way. However, in some scenarios, manual administrative action is required. For any of these unresolved conflicts, the administrator receives notification through administrative alerts. On a high level, the conflict resolution algorithm tries to resolve conflicts as if the operations causing the conflict in a distributed environment apply to a single PingDirectory server instance. For example, if the same entry is added to two different PingDirectory server instances at about the same time, after these operations are replicated, both servers keep only the first entry added. The following image highlights the differences between standalone versus replicated environments. An illustration depicting the process of conflicting operations in standalone environments versus replicated environments. On the left side of the illustration, the standalone environment is presented in a 4-step process depicting the LDAP communication between the directory server and the client. On the right side of the illustration, the replicated environment is presented in a 6-step process. The steps 1 to 6 in the middle of the illustration detail the process of the conflicting operations in standalone, as well as the replicated environments. Steps 1 to 4 depict the LDAP communication between the directory server A and the client and directory server B and the client while steps 5 and 6 depict the failed replication between the servers and conflicting operations * Processing steps 1. Client sends LDAP modify request to directory server and succeeds. 2. Client sends another LDAP modify request that conflicts with the first. 3. In the standalone case, the request is rejected. In the replicated case, the request succeeds. 4. Replication propagates the updates (replicated only). 5. Conflict resolution (replicated only): A ignores the update from B, and B sets the attribute value to the value on A. ## Types of replication conflicts There are two types of replication conflicts: * Naming conflicts Naming conflicts include operations that cause conflicts with the naming of the distinguish name (DN) of the existing or new entries. * Modification conflicts Modification conflicts include operations that result in conflicts in the modification of attributes. ## Naming conflict scenarios The following illustration depicts the naming conflict scenario. An illustration of the naming conflict scenario between Identity Data Store A and Identity Data Store B in 4 steps. The 4 steps are detailed at the bottom of the illustration. The illustration depicts the LDAP communication using a solid blue line between update 1 and Identity Store A (which is step 1) and update 2 and Identity Store B (which is step 2). Replication is depicted with two dotted red lines with one going from Data Store A to B and B to A. Replication is detailed in step 3 * Processing steps 1. The Client sends an update (Add, Delete, or Modify DN) request to server A. 2. The Client sends an update (Add, Delete, or Modify DN) request conflicting with the first request to server A. 3. Replication propagates the updates. 4. Conflict resolution takes place. The following table shows the result of a modification conflict depending on the type of updates that occur. The code does not compare change sequence numbers (CSNs) but applies operations in the order they were received. This might lead to inconsistent replays. For all of the naming conflict scenarios, assume the following: * Update 1 was applied at PingDirectory server 1. * Update 2 was applied at PingDirectory server 2. * Update 1 occurred shortly before Update 2 so that PingDirectory server 2 received Update 1 after Update 2 was applied. **Naming Conflict Scenarios** | Update 1 | Update 2 | Automatic Resolution? | Result of Conflict Resolution at PingDirectory server 2 When Update 1 is received | | ------------------------------ | ------------------------------------------------------ | --------------------- | ----------------------------------------------------------------------------------------- | | `Modify` | `Delete` | Yes | `Modify` is discarded. | | `Modify` | `Modify DN` | Yes | New entry is located based on the entryUUID and `Modify` is applied to the renamed entry. | | `Delete` | `Delete` | Yes | `Delete` operation is ignored. | | `Delete` | `Modify DN` | Yes | `Delete` operation is applied to the renamed entry. | | `Delete` of A | `Add` of B under A | Yes | Entry B is renamed and Entry A is deleted. | | `Modify DN` | `Delete` of the same entry targeted by the `Modify DN` | Yes | `Modify DN` operation is ignored. | | `Modify DN` with a new parent | `Delete` of parent | No | The entry targeted in the `Modify DN` operation is marked as a conflict entry. | | `Modify DN` with a new parent | `Modify DN` of the parent | Yes | The entry is moved under the new DN of the parent. | | `Modify DN` of A with new DN B | `Modify DN` of C with new DN B | No | A and B will be conflict entries. | | `Add`A | `Modify DN` of the parent of A | Yes | The entry is added under the new DN of the parent. | | `Add`A | `Delete` of the parent of A | No | The added entry is marked as a conflict entry. | | `Add`A | `Add` A with same set of attributes | Yes | The entryUUID of the incoming Add operation applied to the existing entry. | | `Add`A | `Add` A with different set of attributes (or values) | No | The existing entry is marked as a conflicting entry and the incoming `Add` is executed. | ## Modification conflict scenarios Modification conflicts resolve automatically and no manual action is required. The `LDAPModify` operation allows the following modification types: * Add of one or more values * Delete of one or more values or the entire attribute * Replacement of all values | | | | - | ---------------------------------------------------------------------------- | | | Replication does not currently support the increment LDAP modification type. | The following illustration presents a modification conflict scenario. An illustration of a modification conflict scenario between Data Store A, LDAP Client A, Identity Data Store B, and LDAP Client B in 7 steps * Processing steps 1. LDAP client A sends a `modify` request to directory server A. 2. LDAP client B sends a conflicting `modify` request to directory server B. 3. Directory server A applies the modification. 4. Directory server B applies the modification. 5. The LDAP clients receive successful responses. 6. Replication propagates the updates. 7. Conflict resolution on directory server A updates the entry to reflect the value on directory server B. Conflict resolution on directory server B ignores the update received from directory server A. The following table shows the result of a modification conflict depending on the type of updates that occur. For all of the operations in the table, assume the following: * LDAP Modify 1 was applied at PingDirectory server 1. * LDAP Modify 2 was applied at PingDirectory server 2. * LDAP Modify 1 occurred shortly before LDAP Modify 2, so that PingDirectory server 2 received LDAP Modify 1 after LDAP Modify 2 was applied. **Modification Conflict Scenarios** | Modify 1 | Modify 2 | Result of Conflict Resolution at PingDirectory server 2 When Modify 1 is received | | --------------------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------- | | `Add` of a single-value attribute | `Add` of the same attribute with a different value | Incoming `Modify` is ignored. | | `Delete` of a single-valued attribute | Replacement of the value of the same attribute | Incoming `Delete` is ignored. | | Replacement of a single-valued attribute | `Delete` of the same attribute | Incoming Replacement is ignored. | | `Delete` some values from a multi-valued attribute | `Delete` some values from a multi-valued attribute | Incoming `Delete` is ignored. | | `Delete` a multi-valued attribute | `Delete` of the same multi-valued attribute | Incoming `Delete` is ignored. | | `Delete` a multi-valued attribute | `Add` the same multi-valued attribute | Incoming `Delete` is ignored. | | `Delete` value X from a multi-valued attribute | `Delete` value X from the same multi-valued attribute | Incoming `Delete` is ignored. | | `Delete` value X from a multi-valued attribute | `Add` value Y to the same multi-valued attribute | `Delete` of value X is applied. | | `Delete` value X from a multi-valued attribute | `Delete` value Y from the same multi-valued attribute | `Delete` of value X is applied. | | `Delete` value X from a multi-valued attribute | Replace all values of the same multi-valued attribute | Incoming `Delete` is ignored. | | `Add` of values X and Y to a multi-valued attribute | `Delete` value X from the same multi-valued attribute | Only value Y is added. | | `Delete` value X from a multi-valued attribute | `Add` of values X and Y to the same multi-valued attribute | Incoming `Delete` is ignored. |