[Date Prev][Date Next] [Chronological] [Thread] [Top]

hidden databases

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/