This example seems pretty straightforward.
Pierangelo Masarati wrote:
# shadow; hidden
database bdb
suffix "dc=example,dc=com" hidden (*)
syncrepl ...
# translucent; visible
database bdb
suffix "dc=example,dc=com"
overlay translucent
translucent relay (*)
relay "dc=example,dc=com" hidden (*)
Commands with (*) are not valid right now; I'm just trying to see how
things could be implemented.
- the "suffix <namingcontext> hidden" would mark a database as "hidden";
since it's a syncrepl, it would sync with some remote one, but it wouldn't
be directly accessible.
- the "translucent relay" would instruct the translucent overlay to use an
instance of back-relay instead of the default back-ldap to proxy
- the "relay <namingcontext> hidden" would instruct the back-relay to
proxy a specific database that is "hidden"; this would allow it to lookup
a database that otherwise cannot be found by regular select_backend().
Operations within the "dc=example,dc=com" naming context would be served
by the second database, the public one, and would pass thru the
translucent overlay to allow local writes before accessing the "hidden"
shadow database.
What's less obvious to me is how to handle multiple hidden DBs with the
same context. E.g., if I want several replicas of a context:
database ldap
suffix dc=example,dc=com hidden
uri ldap://slave1
syncrepl ...
database ldap
suffix dc=example,dc=com hidden
uri ldap://slave2
syncrepl ...
I was thinking that one might want to actually run a query against one
of these servers to retrieve the contextCSN, to monitor how the
replication has progressed. But it would make more sense to just query
the slave directly for that, so this probably isn't a big problem.
--
-- 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/
