upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-12-24 08:39:37 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

More syncrepl cleanup

Browse source
This commit is contained in:
Howard Chu 2005-01-14 06:53:16 +00:00
parent 7189b4f540
commit 39c89d9661
2 changed files with 22 additions and 67 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
doc/guide/admin/slapdconfig.sdf
View file

@ -430,7 +430,6 @@ H4: syncrepl
> [sizelimit=<limit>]
> [timelimit=<limit>]
> [schemachecking=on|off]
> [updatedn=<DN>]
> [bindmethod=simple|sasl]
> [binddn=<DN>]
> [saslmech=<mech>]
@ -507,15 +506,6 @@ required by the schema definition.
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
@ -597,33 +587,6 @@ containing the database and associated indices live.
> 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.

52
doc/guide/admin/syncrepl.sdf
View file

@ -232,30 +232,25 @@ yielded a greater {{EX:entryCSN}} than was previously recorded in the
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
@ -271,9 +266,8 @@ specification is defined in {{slapd.conf}} (5) of the consumer server,
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
@ -307,15 +301,12 @@ since the last checkpoint, a new checkpoint is performed.
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
@ -331,7 +322,7 @@ A more complete example of the {{slapd.conf}} content is thus:
>
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 0 100
> syncprov-sessionlog 100
H3: Set up the consumer slapd
@ -366,7 +357,9 @@ polling ({{refreshOnly}}) mode of synchronization once a day. It will
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.
@ -386,21 +379,20 @@ H3: Start the provider and the consumer slapd
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.