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...