--- title: Replication conflicts description: This section provides detailed information about the mechanisms and possible scenarios behind replication conflicts. component: pingdirectory version: 11.1 page_id: pingdirectory:pingdirectory_server_administration_guide:pd_ds_replication_conflicts canonical_url: https://docs.pingidentity.com/pingdirectory/11.1/pingdirectory_server_administration_guide/pd_ds_replication_conflicts.html llms_txt: https://docs.pingidentity.com/pingdirectory/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md 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 replication-repair-behavior: Replication repair behavior modification-conflict-scenarios: Modification conflict scenarios --- # Replication conflicts This section provides detailed information about the mechanisms and possible scenarios behind replication conflicts. Updates to entries on PingDirectory servers in a replication topology can happen independently because replication guarantees only eventual consistency, not strong consistency. The eventual consistency model enables conflicting changes to be applied to different PingDirectory server instances. In most cases, the PingDirectory server can resolve these conflicts automatically and consistently. However, some scenarios require manual administrative action. For any of these unresolved conflicts, the administrator receives notification through administrative alerts. At a high level, the conflict resolution algorithm tries to resolve conflicts as though the operations occurred on 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 and 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 PingDirectory 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 server A and the client and server B and the client, while steps 5 and 6 depict the failed replication between the servers and conflicting operations * Processing steps 1. The client sends an LDAP `modify` request to the PingDirectory server and succeeds. 2. The client sends another LDAP `modify` request that conflicts with the first. 3. In the standalone case, the server rejects the request. In the replicated case, the request succeeds. 4. Replication propagates the updates (replicated only). 5. Conflict resolution (replicated only): Server A ignores the update from server B, and server B sets the attribute value to the value on server 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 distinguished 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 `moddn`) request to server A. 2. The client sends an update (`add`, `delete`, or `moddn`) request conflicting with the first request to server B. 3. Replication propagates the updates. 4. Conflict resolution takes place. The following table shows the result of a naming conflict, depending on the type of updates that occur. The code doesn't 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. * The `APPLY_REPAIR_READDED_ENTRY` property is enabled. Learn more in [Replication repair behavior](#replication-repair-behavior). **Naming Conflict Scenarios** | Update 1 | Update 2 | Automatic resolution | Result of conflict resolution at server 2 when Update 1 received | | -------------------------- | ---------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `modify` | `delete` | Yes | `modify` is normally discarded.If the entry was deleted with the Replication Repair control and re-added, the `modify` gets applied to the re-added entry. | | `modify` | `moddn` | Yes | New entry is located based on the entryUUID and `modify` is applied to the renamed entry. | | `delete` | `delete` | Yes | `delete` operation is normally ignored.If the entry was deleted with the Replication Repair control and re-added, the `delete` gets applied to the re-added entry. | | `delete` | `moddn` | 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. | | `moddn` | `delete` of the same entry targeted by the `moddn` | Yes | `moddn` operation is ignored. | | `moddn` with a new parent | `delete` of parent | No | The entry targeted in the `moddn` operation is marked as a conflict entry. | | `moddn` with a new parent | `moddn` of the parent | Yes | The entry is moved under the new DN of the parent. | | `moddn` of A with new DN B | `moddn` of C with new DN B | No | A and C will be conflict entries. | | `add` A | `moddn` 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 is 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. | ### Replication repair behavior When you use the Replication Repair control to [fix a naming conflict](pd_ds_troubleshoot_replication.html#fixing-a-naming-conflict), you might need to delete an entry on one replica and then add it back to that same replica. This creates a situation where the entry exists on the repaired replica with a different UUID than on other replicas. When the repaired replica receives a replicated `modify` or `delete` operation, and there's a UUID mismatch for the target DN, the server checks whether the original UUID still exists within the replication topology: * If the UUID isn't present, the replica accepts the operation and applies it to the re-added entry. * If the UUID is present, the replica discards the operation. The renamed entry can receive the operation through a UUID redirect. This behavior is controlled by the `APPLY_REPAIR_READDED_ENTRY` system property, which is enabled by default. To disable this behavior and cause the replica to reject operations with a UUID mismatch, do the following: 1. In the server's `config/java.properties` file, add the following line to the `start-server.java-args` section: ``` -Dcom.unboundid.directory.server.replication.plugin.ReplicationDomain.APPLY_REPAIR_READDED_ENTRY=false ``` For example: ``` start-server.java-args=-server -Xmx768m -Xms768m ... \ -Dcom.unboundid.directory.server.replication.plugin.ReplicationDomain.APPLY_REPAIR_READDED_ENTRY=false ``` 2. Save the file. 3. Apply your changes by running `bin/dsjavaproperties`. 4. Restart the server. ## 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 * Replace all values | | | | - | --------------------------------------------------------------------------- | | | Replication doesn't 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 server A. 2. LDAP client B sends a conflicting `modify` request to server B. 3. Server A applies the modification. 4. Server B applies the modification. 5. The LDAP clients receive successful responses. 6. Replication propagates the updates. 7. Conflict resolution on server A updates the entry to reflect the value on server B. Conflict resolution on server B ignores the update received from 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 server 2 when Modify 1 received | | -------------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------------- | | `add` of a single-valued 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 multivalued attribute | `delete` some values from a multivalued attribute | Incoming `delete` is ignored. | | `delete` a multivalued attribute | `delete` of the same multivalued attribute | Incoming `delete` is ignored. | | `delete` a multivalued attribute | `add` the same multivalued attribute | Incoming `delete` is ignored. | | `delete` value X from a multivalued attribute | `delete` value X from the same multivalued attribute | Incoming `delete` is ignored. | | `delete` value X from a multivalued attribute | `add` value Y to the same multivalued attribute | `delete` of value X is applied. | | `delete` value X from a multivalued attribute | `delete` value Y from the same multivalued attribute | `delete` of value X is applied. | | `delete` value X from a multivalued attribute | Replace all values of the same multivalued attribute | Incoming `delete` is ignored. | | `add` of values X and Y to a multivalued attribute | `delete` value X from the same multivalued attribute | Only value Y is added. | | `delete` value X from a multivalued attribute | `add` of values X and Y to the same multivalued attribute | Incoming `delete` is ignored. |