From 39c89d9661f01b49f490ab403cb39cea02ff7130 Mon Sep 17 00:00:00 2001 From: Howard Chu Date: Fri, 14 Jan 2005 06:53:16 +0000 Subject: [PATCH] More syncrepl cleanup --- doc/guide/admin/slapdconfig.sdf | 37 ----------------------- doc/guide/admin/syncrepl.sdf | 52 ++++++++++++++------------------- 2 files changed, 22 insertions(+), 67 deletions(-) diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf index 27316af998..8ddb72c888 100644 --- a/doc/guide/admin/slapdconfig.sdf +++ b/doc/guide/admin/slapdconfig.sdf @@ -430,7 +430,6 @@ H4: syncrepl > [sizelimit=] > [timelimit=] > [schemachecking=on|off] -> [updatedn=] > [bindmethod=simple|sasl] > [binddn=] > [saslmech=] @@ -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 - -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:}}. -The first syncrepl search request having the same {{EX:}} 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:}}. Excessive entries are removed from the store -in the FIFO order. Both {{EX:}} and {{EX:}} are -non-negative integers. {{EX:}} 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. diff --git a/doc/guide/admin/syncrepl.sdf b/doc/guide/admin/syncrepl.sdf index c21895bc4b..317e0162d9 100644 --- a/doc/guide/admin/syncrepl.sdf +++ b/doc/guide/admin/syncrepl.sdf @@ -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,}} -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. - is the replica ID uniquely identifying the replica locally in the -syncrepl consumer server. 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 +> syncprov-sessionlog -directive, where {{}} is the ID of the per-scope session log -in the provider server and {{}} is the maximum number of -session log entries the session log can record. {{}} -is an integer no longer than 3 decimal digits. If the consumer -server sends a synchronization cookie containing {{sid=}} -where {{}} matches the session log ID specified in the directive, -the LDAP Sync search is to utilize the session log. +directive, where {{}} 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=}}, {{sid=}}, and +supported syncrepl cookie fields are {{csn=}} and {{rid=}}. {{}} represents the current synchronization state -of the consumer replica. {{}} is the identity of the per-scope -session log to which this consumer will be associated. {{}} identifies +of the consumer replica. {{}} 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 {{}} and {{}} have no more than 3 decimal digits. +The {{}} must have no more than 3 decimal digits. The command line cookie overrides the synchronization cookie stored in the consumer replica database. -- 2.39.5