I just solve the problem and the BDB replication can work well with the OpenLDAP. The back-bdb caching mechanism is not removed. I will test the performance while deploying back-bdb configuration in OpenLDAP.

----Seuler 2006/12/14, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>>: This is a pointless exercise. > --On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi )" > <seuler.shi(a)gmail.com <mailto:seuler.shi@gmail.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 group in >> BDB, once the master crashes, a new >> master will be elected by BDB and the replication group can >> still work well. All the parameters >> concerning master election in BDB can be configured by user. >> 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 servers. Relying solely on BDB replication does not provide such power or flexibility. >> As the replication mechanism reaches synchronizations by >> transferring write requests to the replicas, >> this may be less efficient compared with BDB replication. So >> 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 >> replication? 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 maintained by >> 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 effort.