[Date Prev][Date Next] [Chronological] [Thread] [Top]

strange error - missing data after migration



hi openldap-list,

i really need your help: after migrating our slave ldap server from ldbm
backend to bdb backend  (due to transaction safety, avoid 2GB filesize
limitation etc...) and in the same step also from 2.1.30 to 2.2.13 i
noticed strange errors. the slave cannot find the same data like the
master does.

i will give you an example:

SLAVE with bdb backend Berkeley DB 4.2.52 (Openldap 2.2.13 on CentOS 4.2
x86_64):
$ ldapsearch -v -b "cn=netm,ou=resellers,ou=netmservice,o=netmldap" -LLL
-x cn=3004983 cn
ldap_initialize( <DEFAULT> )
filter: cn=3004983
requesting: cn


log entry:

Nov 15 15:14:31 remus slapd[12268]: conn=122268 op=1 SRCH
base="cn=netm,ou=resellers,ou=netmservice,o=netmldap" scope=2 deref=0
filter="(cn=3004983)"
Nov 15 15:14:31 remus slapd[12268]: conn=122268 op=1 SRCH attr=cn
Nov 15 15:14:31 remus slapd[12268]: conn=122268 op=1 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Nov 15 15:14:31 remus slapd[12268]: conn=122268 op=2 UNBIND

see nentries=0 - so requested entry not found !

and here the same query on MASTER with ldbm backend Berkeley DB 4.1.25
(Openldap 2.1.30 on Redhat 9)

ldapsearch -v -b "cn=netm,ou=resellers,ou=netmservice,o=netmldap" -LLL
-x cn=3004983 cn
ldap_initialize( <DEFAULT> )
filter: cn=3004983
requesting: cn

dn: cn=3004983,cn=netm,ou=resellers,ou=netmservice,o=netmldap
cn: 3004983

log entry:

Nov 15 15:14:39 hestia slapd[20068]: conn=2373 op=1 SRCH
base="cn=netm,ou=resellers,ou=netmservice,o=netmldap" scope=2
filter="(cn=3004983)"
Nov 15 15:14:39 hestia slapd[20068]: conn=2373 op=1 SRCH attr=cn
Nov 15 15:14:39 hestia slapd[20068]: conn=2373 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Nov 15 15:14:39 hestia slapd[25203]: conn=2373 op=2 UNBIND

as you can see the master finds the requested entry and shows the needed
cn attribute but the slave shows up nothing... i'm clueless...

the slave was created with the latest slapcat ldif from the master and
master was shutdown while the slave was build. what is even more strange
is that for example the dn
cn=4795,cn=SMSGW,ou=portals,cn=3004983,cn=netm,ou=resellers,ou=netmservice
 ,o=netmldap which is below the above mentioned dn is found. see example
(on SLAVE):

$ ldapsearch -v -b "cn=netm,ou=resellers,ou=netmservice,o=netmldap" -LLL
-x cn=4795 cn
ldap_initialize( <DEFAULT> )
filter: cn=4795
requesting: cn

dn:
cn=4795,cn=SMSGW,ou=portals,cn=3004983,cn=netm,ou=resellers,ou=netmservice
 ,o=netmldap
cn: 4795

when i'm manually modifying the dn:
cn=3004983,cn=netm,ou=resellers,ou=netmservice
 ,o=netmldap on the master and the slurpd will send update to the slave
i cannot see any error in the replog file (smoothly truncated) nor in
the slapd.log.

am i missing some major changes between the versions of openldap or
sleepycat db that can cause this strange effect? broken index?

please do not hesitate to ask for more detaild info if needed!

thanx a lot in advance.

regards,
carsten

Attachment: signature.asc
Description: This is a digitally signed message part