2006/12/14, Howard Chu <firstname.lastname@example.org <mailto:email@example.com>>:
This is a pointless exercise.
> --On Thursday, December 14, 2006 2:27 PM +0800 "çæ(Seuler.shi )"
> <firstname.lastname@example.org <mailto:email@example.com>> wrote:
>> Dear Quanah:
>> Because the replication features provided by
OpenLDAP do not
>> meet our software requirement.
>> If there are N slaves and 1 master in a replication
>> BDB, once the master crashes, a new
>> master will be elected by BDB and the replication
>> still work well. All the parameters
>> concerning master election in BDB can be configured
>> This will be more portable.
OpenLDAP mirrormode allows automatic promotion of a slave to a master.
Using LDAP for the control protocol is far more portable. It provides an
open, standard protocol for managing all of the servers. Using
back-config on each server will allow you to tune all of the server
parameters, including the underlying BDB parameters, from anywhere on
the network, using any of a variety of LDAP-enabled clients.
Using LDAP for the replication protocol is far more portable. It allows
data to be replicated to any LDAP-aware server, not just other OpenLDAP
Relying solely on BDB replication does not provide such power or
>> As the replication mechanism reaches synchronizations by
>> transferring write requests to the replicas,
>> this may be less efficient compared with BDB
>> we need to compare these two method.
Transmitting a single LDAP write operation over the network is far more
bandwidth-efficient than transmitting the many database pages that will
be dirtied by a single LDAP write operation.
>> Would you tell me why OpenLDAP do not support BDB
Because BDB replication offers no advantages for OpenLDAP's use cases.
>> BDB replication mechanism will operate slave databases
>> directly without inform the upper layer LDAP.
>> The information such as index, ID and so on
>> OpenLDAP may be inconsistent with the
>> content of database. I try to mend the source code of
>> OpenLDAP to let every "ldapsearch" operation
>> find entry info in database directly, but I failed:(
>> I am expecting your comments.
The only way to make it work is by removing all of the back-bdb caching
mechanisms. Performance will be extremely slow. You will lose a
significant degree of usability and gain no benefit in return for this