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
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.
3.) Is it necessary that one subordinate have all indexes from all
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
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.
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.
I thank you for help in advance !
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/