PingDirectory

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.

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, 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.