[Date Prev][Date Next]
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
>>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
>>bandwidth, prevent failures due to broken link etc.), which would
>>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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support