This section provides in-depth information about the mechanisms and possible scenarios behind replication conflicts.
Updates to the 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 server instances. In most cases, the 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 server instance. For example, if the same entry is added to two different 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.
- Client sends LDAP modify request to directory server and succeeds.
- Client sends another LDAP modify request that conflicts with the first.
- In the standalone case, the request is rejected. In the replicated case, the request succeeds.
- Replication propagates the updates (replicated only).
- Conflict resolution (replicated only): A ignores the update from B. Be sets the attribute value to the value on A.