[Date Prev][Date Next]
Re: syncrepl_del_nonpresent and syncrepl issues.
Jorgen Lundman wrote:
Jorgen Lundman wrote:
Solaris 10 x86
/var/log/slaplog.20100413.gz:Apr 13 15:07:31 ldapslave03.unix
slapd: [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
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: [ID 542995 local4.debug] slapd sh
utdown: waiting for 1 threads to terminate
May 11 14:35:48 ldapslave00.unix slapd: [ID 486161 local4.debug] slapd st
May 11 14:36:15 ldapslave00.unix slapd: [ID 702911 local4.debug] @(#) $Op
enLDAP: slapd 2.3.41 (May 7 2010 11:24:55) $
May 11 14:36:15 ldapslave00.unix slapd: [ID 100111 local4.debug] slapd st
May 11 14:36:16 ldapslave00.unix slapd: [ID 804257 local4.debug] do_syncr
ep2: rid 279 LDAP_RES_INTERMEDIATE - SYNC_ID_SET
May 11 14:36:16 ldapslave00.unix slapd: [ID 561622 local4.debug] syncrepl
_del_nonpresent: rid 279 be_delete DNSHostName=roger,DNSZoneName=test-this.com,o
So I have a test-case to work with.
As a side note, I do notice that if I then further executed:
.. the slave ignores it, then ..
the slave syncs this fine and we are back in business and consistent again.
I started working on upgrade path, I picked:
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
Jorgen Lundman | <email@example.com>
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)