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.
Within our infrastructure there is the order of 1000 Grid services each of which runs its own LDAP server that contains information about its structure and state under the DN mds-vo-name=resource,o=grid. Each institute that that operates a Grid service (in the order of 300 distributed globally), runs an LDAP server containing the consolidated information from all services within its domain under the DN mds-vo-name=site-name,o=grid. In addition, there are about 70 top-level LDAP servers distributed globally that contain the consolidated information from all sites using the DN mds-vo-name=local,o=grid.
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.
http://lfield.web.cern.ch/lfield/bdii-slapd.conf-basic-rep
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.
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?
Also, has anyone done any scalability/reliability tests with syncrepl?
Thanks,
Laurence