---
title: Replication conflicts
description: Replication is eventually consistent by design to support basic write availability. Changes are applied locally and then replayed to remote replicas. This means it's possible to have conflicts. A replication conflict arises when incompatible changes are made concurrently to multiple read-write replicas.
component: pingds
version: 8.1
page_id: pingds:config-guide:repl-conflict
canonical_url: https://docs.pingidentity.com/pingds/8.1/config-guide/repl-conflict.html
revdate: 2025-10-22T14:42:39Z
keywords: ["LDAP", "Replication", "Setup & Configuration", "Troubleshooting"]
---

# Replication conflicts

Replication is eventually consistent by design to support basic write availability. Changes are applied locally and then replayed to remote replicas. This means it's possible to have conflicts. A replication conflict arises when incompatible changes are made concurrently to multiple read-write replicas.

Two types of conflicts happen: modify conflicts and naming conflicts. Modify conflicts involve concurrent modifications to the same entry. Naming conflicts involve other operations that affect the DN of the entry.

Replication resolves modify conflicts, and many naming conflicts by replaying the changes in the correct order. To determine the relative order in which changes occurred, replicas retain historical information for each update. This information is stored in the target entry's `ds-sync-hist` operational attribute.

Replication resolves these conflicts automatically using the historical information to order changes correctly:

* The attributes of a given entry are modified concurrently in different ways on different replicas.

* An entry is renamed on one replica while being modified on another replica.

* An entry is renamed on one replica while being renamed in a different way on another replica.

* An entry is deleted on one replica while being modified on another replica.

* An entry is deleted and another entry with the same DN added on one replica while the same entry is being modified on another replica.

Replication cannot resolve these particular naming conflicts. You must resolve them manually:

* Different entries with the same DN are added concurrently on multiple replicas.

* An entry on one replica is moved (renamed) to use the same DN as a new entry concurrently added on another replica.

* A parent entry is deleted on one replica, while a child entry is added or renamed concurrently on another replica.

When replication cannot resolve naming conflicts automatically, the server renames the conflicting entry using its `entryUUID` operational attribute. The resulting conflicting entry has a DN with the following form:

```
entryuuid=entryUUID-value+original-RDN,original-parent-DN
```

For each conflicting entry named in this way, resolve the conflict manually:

1. Get the conflicting entry or entries, and the original entry if available.

   This example shows the results of a naming conflict for a `newuser` entry added concurrently on two replicas.

   Notice the `ldapsearch` command uses the [ManageDsaIT control](https://www.rfc-editor.org/rfc/rfc3296.html#section-3) to retrieve the conflict entry, a directory-specific entry whose DN starts with `entryuuid=<entryUUID>+<original-RDN>`. This prevents DS from returning conflict entries to normal searches and confusing client applications.

   ```console
   $ ldapsearch \
    --hostname localhost \
    --port 1636 \
    --useSsl \
    --trustStorePath /path/to/opendj/config/keystore \
    --trustStoreType PKCS12 \
    --trustStorePassword:file /path/to/opendj/config/keystore.pin \
    --bindDN uid=admin \
    --bindPassword password \
    --baseDN dc=example,dc=com \
    --control ManageDsaIt:false \
    "(uid=newuser)"
   ```

   > **Collapse: Show output**
   >
   > ```
   > dn: uid=newuser,ou=People,dc=example,dc=com
   > objectClass: top
   > objectClass: inetOrgPerson
   > objectClass: organizationalPerson
   > objectClass: person
   > mail: newuser@example.com
   > sn: User
   > cn: New User
   > ou: People
   > description: Added on server 1
   > uid: newuser
   >
   > dn: entryuuid=2f1b58c3-4bee-4215-88bc-88202a7bcb9d+uid=newuser,ou=People,dc=example,dc=com
   > objectClass: top
   > objectClass: inetOrgPerson
   > objectClass: organizationalPerson
   > objectClass: person
   > mail: newuser@example.com
   > sn: User
   > cn: New User
   > ou: People
   > description: Added on server 2
   > uid: newuser
   > ```

2. To preserve changes made on the conflicting entry or entries, apply the changes manually.

   The following example shows a modification to preserve both description values:

   ```console
   $ ldapmodify \
    --hostname localhost \
    --port 1636 \
    --useSsl \
    --trustStorePath /path/to/opendj/config/keystore \
    --trustStoreType PKCS12 \
    --trustStorePassword:file /path/to/opendj/config/keystore.pin \
    --bindDn uid=admin \
    --bindPassword password << EOF
   dn: uid=newuser,ou=People,dc=example,dc=com
   changetype: modify
   add: description
   description: Added on server 2
   EOF
   ```

   For additional examples demonstrating how to apply changes to directory entries, refer to [LDAP updates](../ldap-guide/write-ldap.html).

3. After making any necessary changes, manually delete the conflicting entry or entries.

   The following example deletes the conflicting entry:

   ```console
   $ ldapdelete \
    --hostname localhost \
    --port 1636 \
    --useSsl \
    --trustStorePath /path/to/opendj/config/keystore \
    --trustStoreType PKCS12 \
    --trustStorePassword:file /path/to/opendj/config/keystore.pin \
    --bindDN uid=admin \
    --bindPassword password \
    entryuuid=2f1b58c3-4bee-4215-88bc-88202a7bcb9d+uid=newuser,ou=People,dc=example,dc=com
   ```

   For additional examples, refer to [Delete entries](../ldap-guide/write-ldap.html#delete-ldap).