Hi To all,
I'm new with this mailing list. I'm having inconsistency with my current LDAP replication using ldbm database. Authentication (authconfig) on both systems is pointed first to master and 2nd to slave for safety. My current userids are growing to (200,000+) two hundred thousand plus. On my slave, ldapsearch command w/ some of my users it shows but in my master it doesn't. And also, when comparing the /var/lib/ldap/*.dbb files on both systems, the gecos.dbb of slave is greater than master's gecos.dbb by 1MB and the other .dbb files are the same size. Is it safe to copy(scp) the gecos.dbb from slave to master to sync their data?
Here's my current systems:
Master: Redhat AS3 - U6 openldap-clients-2.0.27-20 openldap-devel-2.0.27-20 openldap-servers-2.0.27-20 openldap-2.0.27-20
Slave: Redhat AS3 - U4 openldap-clients-2.0.27-21 openldap-devel-2.0.27-21 openldap-servers-2.0.27-21 openldap-2.0.27-21
Regards,
Dennis Systems Administrator
On 5/15/07, Dennis Gonzales dennis.ece@gmail.com wrote:
Hi To all,
I'm new with this mailing list. I'm having inconsistency with my current LDAP replication using ldbm database. Authentication (authconfig) on both systems is pointed first to master and 2nd to slave for safety. My current userids are growing to (200,000+) two hundred thousand plus. On my slave, ldapsearch command w/ some of my users it shows but in my master it doesn't. And also, when comparing the /var/lib/ldap/*.dbb files on both systems, the gecos.dbb of slave is greater than master's gecos.dbb by 1MB and the other .dbb files are the same size. Is it safe to copy(scp) the gecos.dbb from slave to master to sync their data?
Here's my current systems:
Master: Redhat AS3 - U6 openldap-clients-2.0.27-20 openldap-devel-2.0.27-20 openldap-servers-2.0.27-20 openldap-2.0.27-20
Slave: Redhat AS3 - U4 openldap-clients-2.0.27-21 openldap-devel-2.0.27-21 openldap-servers-2.0.27-21 openldap-2.0.27-21
The size of the files isn't necessarily meaningful, stop replication, shutdown, and slapcat all of your servers to do a better comparison. Then restore whichever has the wrong information from whichever has the right information.
Since your slave seemed to miss some deletes, check for .rej files in slurpd's home.
Your versions are a little different, so scp-ing may or may not work.
You won't get a lot of support on this list for a version of openldap five to seven years out-of-date. I can only recommend upgrading to 2.3 and switching to bdb as it will give you improved data integrity, and performance improvements beyond your wildest dreams. Beyond that, try the vendor of your software packages. (redhat?)
openldap-software@openldap.org