Laurence Field Laurence.Field@cern.ch writes:
I have been investigating the use of syncrepl as a replacement for the mechanism we are currently using in our system and become stuck. Here is the scenario to put the problem in context.
[...]
At the moment the LDAP databases are updated externally via process that polls the LDAP server for all information, which is very inefficient. Syncrepl seems to be a better mechanism to use however, I am having difficulty with one scenario. Using standard syncrepl with a relay, the site-level LDAP server can be configured with the following slapd.conf file.
this slapd.conf is malformed, the updateref parameter is missing.
However, the site LDAP server is a Grid service and needs to publish itself. If I try to just to an LDAP add I get the following message, which I guess is due to the fact that this part of the database is now "owned" by the syncrepl process.
ldap_add: Server is unwilling to perform (53) additional info: shadow context; no update referral
I tried to work around this problem by using another database and some more relays the result of which can be seen in the following file.
http://lfield.web.cern.ch/lfield/bdii-slapd.conf
However, this result with the following error, which suggests that I can't "mask" a database with a relay that points somewhere else.
this slapd.conf is malformed als well, the syncprov parameter has to follow all database related parameters.
bdii-slapd.conf: line 69: <suffix> namingContext "Mds-Vo-name=resource,o=internal" already served by a preceding bdb database serving namingContext "Mds-Vo-name=resource,o=internal"
Does anyone have an example of how to do a syncrepl where a single slapd instance can act as both the consumer and producer?
have a look at tests/scripts/test019
Also, has anyone done any scalability/reliability tests with syncrepl?
Yes I did, cascading databases up to 66 servers and multimaster replication up to 14 hosts and up to 5 M entries. Hardware was Sun Ultrasparc single core 8 GB, rackmounts.
-Dieter