> [sizelimit=<limit>]
> [timelimit=<limit>]
> [schemachecking=on|off]
-> [updatedn=<DN>]
> [bindmethod=simple|sasl]
> [binddn=<DN>]
> [saslmech=<mech>]
If it is turned off, entries will be stored without checking
schema conformance. The default is off.
-The {{EX:updatedn}} parameter specifies the DN in the consumer site
-which is allowed to make changes to the replica. This DN is used
-locally by the syncrepl engine when updating the replica with the
-entries received from the provider site by using the internal
-operation mechanism. The update of the replica content is subject
-to the access control privileges of the DN. The DN should have
-read/write access to the replica database. Generally, this DN
-{{should not}} be the same as {{EX:rootdn}}.
-
The {{EX:binddn}} parameter gives the DN to bind as for the
syncrepl searches to the provider slapd. It should be a DN
which has read access to the replication content in the
> directory /usr/local/var/openldap-data
-H4: sessionlog <sid> <limit>
-
-This directive specifies a session log store in the syncrepl
-replication provider server which contains information on
-the entries that have been scoped out of the replication
-content identified by {{EX:<sid>}}.
-The first syncrepl search request having the same {{EX:<sid>}} value
-in the cookie establishes the session log store in the provider server.
-The number of the entries in the session log store is limited
-by {{EX:<limit>}}. Excessive entries are removed from the store
-in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are
-non-negative integers. {{EX:<sid>}} has no more than three decimal digits.
-
-The LDAP Content Synchronization operation that falls into a pre-existing
-session can use the session log store in order to reduce the amount
-of synchronization traffic. If the replica is not so outdated that
-it can be made up-to-date by the information in the session store,
-the provider slapd will send the consumer slapd the identities of the
-scoped-out entries together with the in-scope entries added to or
-modified within the replication content. If the replica status is
-outdated too much and beyond the coverage of the history store,
-then the provider slapd will send the identities of the unchanged
-in-scope entries along with the changed in-scope entries.
-The consumer slapd will then remove those entries in the replica
-which are not identified as present in the provider content.
-
-
H3: LDBM Database Directives
Directives in this category only apply to a {{TERM:LDBM}} database.
suffix entry's {{EX:contextCSN}} attribute, a checkpoint will be immediately
written with the new value.
-The consumer stores its replica state, which is the provider's
+The consumer also stores its replica state, which is the provider's
{{EX:contextCSN}} received as a synchronization cookie,
-in the {{EX:syncreplCookie}} attribute of the immediate child
-of the context suffix whose DN is {{cn=syncrepl<rid>,<suffix>}}
-and object class is {{EX:syncConsumerSubentry}}.
+in the {{EX:contextCSN}} attribute of the suffix entry.
The replica state maintained by a consumer server is used as the
synchronization state indicator when it performs subsequent incremental
synchronization with the provider server. It is also used as a
provider-side synchronization state indicator when it functions as
a secondary provider server in a cascading replication configuration.
-<rid> is the replica ID uniquely identifying the replica locally in the
-syncrepl consumer server. <rid> is an integer which has no more than
-three decimal digits.
-
-It is possible to retrieve the
-{{EX:syncConsumerSubentry}} by performing an LDAP search with
-the respective entry as the base object and with the base scope.
+Since the consumer and provider state information are maintained in
+the same location within their respective databases, any consumer
+can be promoted to a provider (and vice versa) without any special
+actions.
Because a general search filter can be used in the syncrepl specification,
some entries in the context may be omitted from the synchronization content.
The syncrepl engine creates a glue entry to fill in the holes
in the replica context if any part of the replica content is
subordinate to the holes. The glue entries will not be returned
-as the search result unless {{ManageDsaIT}} control is provided.
+in the search result unless {{ManageDsaIT}} control is provided.
Also as a consequence of the search filter used in the syncrepl
specification, it is possible for a modification to remove an
not in the provider server's configuration file.
The initial loading of the replica content can be performed either
by starting the syncrepl engine with no synchronization cookie
-or by populating the consumer replica by adding and demoting an
+or by populating the consumer replica by adding an
{{TERM:LDIF}} file dumped as a backup at the provider.
-{{slapadd}} (8) supports the replica promotion and demotion.
When loading from a backup, it is not required to perform the initial
loading from the up-to-date backup of the provider content. The syncrepl
The session log is configured by the
-> syncprov-sessionlog <sid> <size>
+> syncprov-sessionlog <size>
-directive, where {{<sid>}} is the ID of the per-scope session log
-in the provider server and {{<size>}} is the maximum number of
-session log entries the session log can record. {{<sid>}}
-is an integer no longer than 3 decimal digits. If the consumer
-server sends a synchronization cookie containing {{sid=<sid>}}
-where {{<sid>}} matches the session log ID specified in the directive,
-the LDAP Sync search is to utilize the session log.
+directive, where {{<size>}} is the maximum number of
+session log entries the session log can record. When a session log
+is configured, it is automatically used for all LDAP Sync searches
+within the database.
Note that using the session log requires searching on the {{entryUUID}}
attribute. Setting an eq index on this attribute will greatly
>
> overlay syncprov
> syncprov-checkpoint 100 10
-> syncprov-sessionlog 0 100
+> syncprov-sessionlog 100
H3: Set up the consumer slapd
bind as {{EX:cn=syncuser,dc=example,dc=com}} using simple authentication
with password "secret". Note that the access control privilege of
{{EX:cn=syncuser,dc=example,dc=com}} should be set appropriately
-in the provider to retrieve the desired replication content.
+in the provider to retrieve the desired replication content. Also
+the search limits must be high enough on the provider to allow the
+syncuser to retrieve a complete copy of the requested content.
The consumer uses the rootdn to write to its database so it
always has full permissions to write all content.
The provider {{slapd}} (8) is not required to be restarted.
{{contextCSN}} is automatically generated as needed:
-it might originally contained in the {{TERM:LDIF}} file,
+it might be originally contained in the {{TERM:LDIF}} file,
generated by {{slapadd}} (8), generated upon changes in the context,
-or generated when the first LDAP Sync search arrived at the provider.
+or generated when the first LDAP Sync search arrives at the provider.
When starting a consumer {{slapd}} (8), it is possible to provide a
synchronization cookie as the {{-c cookie}} command line option
in order to start the synchronization from a specific state.
The cookie is a comma separated list of name=value pairs. Currently
-supported syncrepl cookie fields are {{csn=<csn>}}, {{sid=<sid>}}, and
+supported syncrepl cookie fields are {{csn=<csn>}} and
{{rid=<rid>}}. {{<csn>}} represents the current synchronization state
-of the consumer replica. {{<sid>}} is the identity of the per-scope
-session log to which this consumer will be associated. {{<rid>}} identifies
+of the consumer replica. {{<rid>}} identifies
a consumer replica locally within the consumer server. It is used to relate
the cookie to the syncrepl definition in {{slapd.conf}} (5) which has
the matching replica identifier.
-Both {{<sid>}} and {{<rid>}} have no more than 3 decimal digits.
+The {{<rid>}} must have no more than 3 decimal digits.
The command line cookie overrides the synchronization cookie
stored in the consumer replica database.
projects / openldap / commitdiff