The server's replication mechanism is based on the eventual-consistency model, which is a loosely-connected topology that propagates updates to other servers without waiting for their corresponding replication response messages.
There is a small window of time where updates are not all present on the replicas while the changes are replicating through the system. However, there are deployments that require immediate access to replicated data. In such cases, administrators can configure assured replication, which ensures that replication has completed before the update response is returned to the client.
From the LDAP client's perspective, assured replication has no bearing on the result code of the operation, just on the time in which it takes to receive the response for those requests in which replication assurance is applied. Detailed information regarding assurance processing is available to an LDAP client with awareness of the assured replication control.
The assured replication mechanism uses server location to distinguish between local and remote servers to allow different policies to apply. For example, a common assurance approach is to respond to a client update after all servers in the same location have applied the update and one or more servers in remote locations have received the update. The level of assurance applied to each operation can be explicitly requested by the client, specified by the server configuration using the Replication Assurance Policy, or both.
Assured replication is supported by client requests directly to server, through a server, or both.