Syncrepl
The basic synchronization operation is described in RFC 4533. The protocol is defined such that a persistent database of changes is not required. Rather the set of changes is implied via change sequence number (CSN) information stored in each entry and optimized via an optional session log which is particularly useful to track recent deletes. The model of operation is that a replication client (consumer) sends a "content synchronizing search" to a replication server (provider). The consumer can provide a cookie in this search (especially when it has been in sync with the provider previously). In the OpenLDAP implementation of the RFC 4533, this cookie includes the latest CSN that has been received from the provider (called the contextCSN).
The provider then returns as search results (or, see optimization below, sync info replies) the present (unchanged entry only used in the present phase of the refresh stage) (no attributes), added, modified (represented in the refresh phase as an add with all current attributes), or deleted (no attributes) entries to put the consumer into a synchronized state based on what is known via their cookie. If the cookie is absent or indicates that the consumer is totally out of sync, then the provider will, in the refresh stage, send an add for each entry it has. In the ideal case, the refresh stage of the response contains only a delete phase with just a small set of adds (including those that represent the current result of modifies) and deletes that have occurred since the time the consumer last synchronized with the provider. However, due to limited session log state (also non persistent) kept in the provider, a present phase may be required, particularly including the presentation of all unchanged entries as a means (inefficient) of implying what has been deleted in the provider since the consumer last synchronized.
The search can be done in either refresh or refreshAndPersist mode, which implies what stages occur. The refresh stage always occurs first. During the refresh stage, two phases may occur: present and delete, where present always occurs before delete. The phases are delimited via a sync info response that specifies which phase is completed. The refresh and persist stages are also delimited via such sync info response. An optional optimization to more compactly represent a group of entries that are to be presented or deleted is to use a sync info response containing a syncIdSet that identifies the list of entryUUID values of those entries.
The present phase is differentiated from the delete phase as follows. Entries that present unchanged entries may only be returned in the present phase. Entries that delete entries may only be provided in the delete phase. In either phase, add entries (including adds that represent all current attributes of modified entries) can be returned. At the end of a present phase, each entry that the consumer has that was not identified in an add entry or present response during the present phase is implicitly no longer in the provider and thus must be deleted at the consumer so as to synchronize the consumer with the provider.
Once the persist stage begins, the provider sends search results that indicate only the add, modify and delete of entries (no present unchanged entry indications) for those entries changed since the refresh stage completed. The persist stage continues indefinitely, meaning that search has no final "done" response. By contrast, in the refresh mode only a refresh stage occurs and such stage completes with a done response that also ends the present or delete phase (whichever phase was currently active).
Read more about this topic: OpenLDAP, Replication