Re: syncrepl_del_nonpresent and syncrepl issues.

[Jorgen Lundman <lundman@lundman.net>]

Jorgen Lundman wrote:
> Jorgen Lundman wrote:
> > openldap-2.3.41
> > db-4.2.52.NC-PLUS_5_PATCHES
> > Solaris 10 x86
> /var/log/slaplog.20100413.gz:Apr 13 15:07:31 ldapslave03.unix
> slapd[27475]: [ID 561622 local4.debug] syncrepl_del_nonpresent: rid 329
> be_delete DNSHostName=www,DNSZoneName=$customer.com,ou=dns,dc=$DC (66)


Just information sharing, no current issues...


I spun up some XENs worlds, one for master and one for client, for my own test 
case.

I did the operations of adding a DNS entry A-TYPE to a zone 
("roger.test-this.com" in this case), then deleting said record and watching the 
sync log output of the slave.

Any number of these operations, add->del->add->del, appeared to work correctly.

However, when I did:

1) add "roger.test-this.com"
2) stop slapd on slave.
3) delete "roger.test-this.com"
4) start slapd on slave.

I get the following entries: (I only start slapd, no other operations)

May 11 14:35:47 ldapslave00.unix slapd[28256]: [ID 542995 local4.debug] slapd sh
utdown: waiting for 1 threads to terminate
May 11 14:35:48 ldapslave00.unix slapd[28256]: [ID 486161 local4.debug] slapd st
opped.
May 11 14:36:15 ldapslave00.unix slapd[28264]: [ID 702911 local4.debug] @(#) $Op
enLDAP: slapd 2.3.41 (May  7 2010 11:24:55) $
May 11 14:36:15 ldapslave00.unix slapd[28265]: [ID 100111 local4.debug] slapd st
arting
May 11 14:36:16 ldapslave00.unix slapd[28265]: [ID 804257 local4.debug] do_syncr
ep2: rid 279 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
May 11 14:36:16 ldapslave00.unix slapd[28265]: [ID 561622 local4.debug] syncrepl
_del_nonpresent: rid 279 be_delete DNSHostName=roger,DNSZoneName=test-this.com,o
u=dns,$DC (66)

So I have a test-case to work with.

As a side note, I do notice that if I then further executed:

add "www.test-this.com"

.. the slave ignores it, then ..

del "www.test-this.com"

the slave syncs this fine and we are back in business and consistent again.





I started working on upgrade path, I picked:

db-4.8.30
openldap-2.4.21

I first upgraded the LDAP master. I tried various techniques, since I can't use 
db_upgrade directly. But the new 2.4.21 is happy to sync against the old 2.3.41, 
so I think I will simply run it in parallel until I am sure it has caught up. 
(You guys have a clever way to test and know when LDAP syncrepl has caught up?)

With LDAP master running 2.4.21, and LDAP slave running 2.3.41, the test-case 
still works. Ie, it still breaks.

I then also upgraded LDAP slave to 2.4.21 and I can confirm the problem no 
longer happens. So it has indeed already been fixed. And I have an upgrade path 
to follow...


















--
Jorgen Lundman       | <lundman@lundman.net>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)