PingDirectory

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.

AddA

Modify DN of the parent of A

Yes

The entry is added under the new DN of the parent.

AddA

Delete of the parent of A

No

The added entry is marked as a conflict entry.

AddA

Add A with same set of attributes

Yes

The entryUUID of the incoming Add operation applied to the existing entry.

AddA

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.