--On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi)" 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.
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.
Would you tell me why OpenLDAP do not support BDB
replication?
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.
Because they aren't compatible. I'm guessing standby master may more meet your needs, which will be a part of OpenLDAP 2.4.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
This is a pointless exercise.
--On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi)" 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.
2006/12/14, Howard Chu hyc@symas.com:
This is a pointless exercise.
--On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi)" 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.
=============================================== The bdb replication will ensure the slave's cache as well as the bdb database in disk. I intend to turn off openldap's cache and configure back -bdb with main memory state.
--
-- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/