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

Re: central database on one server, "dislocated" servers in many cities

Tomasz Chmielewski wrote:

Kurt D. Zeilenga wrote:

> Through use of replication in slapd(8), you can do 1) through 4).
> 5) is not possible in slapd(8) as the "central" server would
> be the master server in the outlined scenario.

So you're saying there's no solution for that?
My case sounds so simple, what should one do to solve such a problem?


>> 5) moreover, in each branch, clients should be able to change their passwords,

>>and Samba should be able to add machines to the database automatically.
>>These changes should be added to the local machine (to save time on a tight
>>bandwidth, prevent failures due to broken link etc.), which would then be
>>transferred to the central server, and from there, to the rest of the branch offices.

You can easily do this in realtime, but if you're worried about a slow or broken WAN link that may not perform very well. The problem is if you defer the changes and batch them up, there is no way to guarantee the changes will be applied successfully on the master when they finally get transmitted. Nor is there any way (via LDAP) to associate any failures with the original change requests. I.e., you lose any notion of data consistency, as well as having no recovery mechanism.

For the realtime solution - use the chaining overlay in OpenLDAP 2.2 to force the replicas to directly update the master when a client performs a modification. This guarantees that changes will preserve data consistency, and avoids the problems of client-side referral chasing, but it requires that the master is reachable when a modification is performed.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support