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

Interesting LDAP replication scenario




The title says it all. I'm fairly comfortable with developing against OpenLDAP and have worked on several fairly large deploys. But all have been very straitforward from a replication standpoint. I have in front of me now a replication task that looks fairly tricky -- at least to me...


A picture is worth a thousand words, so here's one that will hopefully make my situation a bit more clear:

http://www.northernwastes.org/~geoff/rep_diagram.png

Now here's a verbal summary of my scenario:

I have a number of "districts", each which contains a number of separate physical sites. All sites in a given district have a common suffix and need to share information. Each district has a separate database. Right now I have replication working in a pretty standard way:


1. An LDAP client submits a modify request of some sort to the slave slapd server.


2. THE slave slapd refers the LDAP client the master slapd.

3. THE master slapd does the modify and writes the change to the replication log.

4. slurpd sends the change to all slave slapd servers in the district.


So far so good. Everything is pretty much by the book. But here's my problem:


Many of my sites are in very rural locations and have very tentative connections to the rest of the world. Connection downtime measured in days is possible in some cases. At many individual sites downtime measured in hours is unfortunately fairly common. When new information is added to any individual site the site slapd instance I need it to to be accessible to the users at that site immediately. There are currently about a hundred of individual sites, with more to be added over time.

Here's what I would _like_ to see:


1. The LDAP client submits a modify request to a site (master? slave?) slapd server


2. This site slapd server immediate does the modify then (if it is available) passes the request to the master slapd server at home base. If not, the site slapd instance periodically checks back until such time as the home base master slapd server becomes available and then passes on the request.

3. The home base master slapd does the modify and writes the change to the replication log.

4. slurpd sends the change to all site (master? slave?) slapd servers in the district _except_ the original location.


Can this scenario be made to work? Is this really the best way to do things, or is there another way?


Any help. thoughts or suggestions at this point would be greatly appreciated...


//glw