How Replication Works

Information from a master naming context is propagated to a replica by the dspushd daemon. This information can also be pulled from the master server by the dspulld daemon running on the replica server. The dspushd and dspulld daemons use the LDAP protocol to update a replica naming context.

A master naming context for which a replica is defined maintains a replication log. Each time the master naming context is updated, the transaction is recorded in the replication log. When the dspushd daemon next runs, it reads the replication log and sends the change to the server that holds the replica naming context. The dsservd server handles update requests from dspushd in the same way that it handles all requests, using the information supplied in the bind request to set the access level granted to dspushd requests. To guarantee that all replication updates are completed, dspushd must bind with the DN defined when the replica naming context was configured. If a different DN is used, write access for all entries may not be granted.

If replication is managed by the slave server, the dspulld daemon compares the master and the replica naming contexts, and performs the necessary updates on the replica.

A replica data store always has a referral pointing to the master data store. If a replica server receives a request to modify an entry, it returns a referral to the client, indicating the master server to be contacted. Once the modification has been made in the master naming context, the change is sent to the replica naming context the next time the dspushd daemon runs.

Any naming context held in the data store, including replica naming contexts, can be replicated to another server.