Re: Replication bug with modrdn changetype (ITS#1562)

[masarati@aero.polimi.it]

enigma@apu.edu wrote:
> 
> Full_Name: Christoph Neumann
> Version: 2.0.21
> OS: Linux (RedHat 7.1)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (216.86.200.213)
> 
> I noticed that our replicated server was crashing.  As soon as I restarted the
> slave server, I would recieve an error very similar to the following in the
> rejection log:
> 
> ERROR: No such object
> replica: auth2:0
> time: 1012261024.0
> dn: uid=lkhan,ou=Students,ou=People,dc=apu,dc=edu
> changetype: modrdn
> newrdn: uid=lraza
> deleteoldrdn: 0
> 
> The most curious thing is: if I do a base search on the slave for the old DN
> *or* the new  DN, the record is returned.  However, the dn is reported as still
> being the old DN.
> 
> ldapsearch -LLL -h auth2.apu.edu -D "cn=admin,dc=apu,dc=edu" -W -x -b
> "uid=lkhan,ou=Students,ou=People,dc=apu,dc=edu" -s base '(objectclass=*)'
> 
> It is almost as if the replicated server was in the middle of the update and
> crashed in an inconsistent state.

Well, the old dn2id is deleted before the ned dn2id is created; of
course
there's no guarantee that the db is synced, but I'd expect none of the 
changes to take place if the crash occurs before they're synced.

Do you mean a search with either the old or the new dn as base
yields the SAME entry with the OLD dn? Odd.

> 
> The master LDAP server does not crash.  It is not in an inconsistent state.
> Only the slave ldap server.

A backtrace of the slave, to determine why it crashed, would help.  
Is the problem repeatable (same/analogous entry, same/analogous 
change resulting in the same disaster)?

Ando

-- 
Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 |
mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy   |
http://www.aero.polimi.it/~masarati