The syncprov (Sync Provider) overlay must be defined for every DIT that is a provider (a master) when using LDAP Content Synchronization (RFC4533) ( syncrepl replication). The overlay can be used with any backend that maintains entryCSN and entryUUID attributes for its entries (currently only bdb and hdb). The overlay creates a contextCSN attribute in the root entry of the database(DIT) to control synchronization.
To increase synchronization performance it is recommended that an eq index on the entryCSN attribute for the DIT be defined when using this overlay. Slapd.conf example:
database bdb ... index contextCSN eq ...
OLC (cn=config) equivalent would use olcIndex: contextCSN eq
A syncprov overlay (and any associated directives) must be defined for each DIT (database section) which is to act as a provider for a replication operation. The syncprov overlay is defined at the end of the section but before any database specific parameters. Slapd.conf examples of use:
# first DIT definition database bdb ... # DIT will act as a provider overlay syncprov ... # optional database parameters cachesize 10000 ... # second DIT definition database bdb ... # DIT will NOT act as a provider # optional database parameters cachesize 10000 ... # third DIT definition database bdb ... # DIT will act as a provider overlay syncprov ... # optional database parameters cachesize 10000 ...
In the case of OLC (cn=config) each overlay is defined as a child entry of its database paranet entry (using overlays in OLC (cn=config)).
In a typical Master-Slave replication the LDAP server containing the master DIT (provider) will define the syncprov overlay and the slave LDAP server (consumer) will define a syncrepl directive (olcSyncRepl attribute for OLC) to describe access to the provider. More information and configuration examples of replication configurations. The only exception is in multi-master configurations when each DIT is both a master (provider) and a slave (consumer).
The following syncprov attributes appear in the syncprov overlay entry in OLC (cn=config) or after the overlay syncprov directive in slapd.conf or .
olcSpCheckpoint: ops minutes syncprov-checkpoint ops minutes
This attribute/directive controls maintenance of the contextCSN which is normally a memory only value but is written to the database on normal server termination and loaded from the database during server start-up operations. The attribute/directive may be used to force the provider to write the contextCSN to the underlying database after a successful write operation after either every ops write operations or more than minutes time have passed since the last contextCSN database update (or checkpoint). syncprov-checkpoint is disabled by default. This directive is designed to minimise the amount of consumer synchronization activity required in the event that the master (provider) DIT server crashes. Example:
overlay syncprov # update the contextCSN in the database after either # 100 successful write operations OR # more than 5 minutes have elapsed # since the last time the contextCSN was written to the database olcSpCheckPoint: 100 5 syncprov-checkpoint 100 5
olcSpNoPresent: TRUE | FALSE syncprov-nopresent TRUE | FALSE
If set TRUE, the Present phase of refreshing will be bypassed. This value should only be set TRUE for a syncprov instance used with a log database such as one managed using the accesslog overlay. The default is FALSE.
olcSpReloadHint: TRUE | FALSE syncprov-reloadhint TRUE | FALSE
Indicates the overlay should honor the reloadHint flag in the Sync Control (Note: certain version 2.3 clients did not set the reloadhint flag correctly). It must be set TRUE when using the accesslog overlay for delta-synchonization. The default is FALSE. olcSpReloadhint (syncprov-reloadhint) may be used by the consumer requesting the replication operation to indicate that it wishes to force a complete transfer of the DIT irrespective of any other settings or values - such as the Sync Cookie.
olcSpSessionlog: ops syncprov-sessionlog ops
Indicates that a session log for recording information about write operations made on the database should be maintained by the provider. ops specifies the number of operations that are recorded in the log. All write operations (except Adds) are recorded in the log. When using the session log, it is helpful to set an eq index on the entryUUID attribute in the underlying provider database.
This session log may be used during replication synchronization operations to minimise consumer updates primarily in refreshOnly mode. Since the provider is not configured to know how many replica consumers will be requesting synchronization, for optimal efficiency the value defined in this directive should allow for the expected maximum number of changes between the slowest (longest) re-sync interval (set by the interval parameter of the syncrepl directive) in the consumer. If the session log does not contain enough information the provider executes a full re-synchronization sequence from the last known point.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
3 ldap objects
4 install ldap
7 replica & refer
10 ldap api
14 ldap tools
notes & info
rfc's & x.500
This work is licensed under a Creative Commons License.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox