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.
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.
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 !
Regards
Sepp