Re: several replication questions (2nd try)

[Sepp <openldap@ifi.lmu.de>]

Hello Howard,

at first, thank you for your very interesting answers !

> Sepp wrote:
>   
>> Hello,
>>
>> here is our three-level concept for replication,
>> 1 provider, 2 subproviders, 10 consumers:
>> * the provider should replicate most of his subtrees to both subproviders
>> * a few subtrees should be replicated from the 2 subproviders to the provider
>> * subprovider no1 should replicate his whole tree to 5 consumers
>> * subprovider no2 should replicate his whole tree to the other 5 consumers
>> * a few user entries (eg. the replication manager) should be replicated from
>>   subprovider no.1 to subprovider no.2, and from 1 consumer to the other 9 comsumers
>>
>> Here are the questions concerning this config:
>>
>> 1.) Is the best (and perhaps only ?) way for an implementation
>> to devide the DITs in subordinate databases with the according syncrepl
>> statements (similar to openldap-2.3.28/tests/data/slapd-glue-syncrepl*.conf,
>> we have a successful test config for that)
>>     
>
> For now that is the only way.
>
>   
>> 2.) Do we need the glue overlay in this context (I don't think so) ?
>>     
>
> You only need glue if you want the overall database to appear unified, 
> i.e. such that a subtree search from the root will return results from 
> all of the databases.
>
>   
This was the point of my question:
I have no "overlay glue" directive in my slapd.conf, but with the
following command
I get the values of all description attributes in all subordinates:

ldapsearch -x -h localhost -p 389 -b "o=test,c=de" "description=*"

LDAP Browsing over all subordinate limits is no problem either.

Did I get you right that this should not really work without "overlay
glue" ?

>> 3.) Is it necessary that one subordinate have all indexes from all other
>> subordinates (I do think so, to prevent "index_param failed" error messages
>> when searching from top level)
>>     
>
> Every database should have whatever indexing configured as needed for 
> whatever queries it will have to answer.
>
>   
>> 4.) Sorry, when that's a FAQ: Is it a must that the updatedn is not the
>> same like the rootdn or is it only a recommendation ? Is this for security
>> reasons or why ?
>>     
>
> In terms of syncrepl there is no updatedn, so the question is moot. In 
> terms of slurpd it's to prevent confusion when an administrator attempts 
> to write on a slave; if the rootdn and updatedn are identical then the 
> write will be allowed even though it may be improperly formatted.
>
>   
In older manpages of slapd.conf (and in one new book) I found that
syncrepl has the option 
updatedn=<dn> and that there is another "updatedn" which is only
applicable when
using slurpd. This is obsolete ?
Btw, why is the very important option "exattrs" not part of the syncrepl
description
in the slapd.conf-Manpage ?

>> 5.) With slurpd it is possible to replicate more than one subtrees
>> from one database with several "suffix"-statements. How can I do
>> that with syncrepl ? I didn't find a way to define more than
>> one "searchbase" per "syncrepl rid" or to define more than one
>> "syncrepl rid" per "database".
>>     
>
> The feature allowing multiple syncrepl targets in a single database was 
> present in OpenLDAP 2.2 but dropped for 2.3 because it never worked in 
> 2.2. Since there were so many usability issues with syncrepl in 2.2 we 
> decided to simplify it in 2.3 just to get it to a stable working state. 
> In 2.4 we will probably re-introduce support for multiple targets, but 
> that code has not been written yet.
>   

Thanks !