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

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[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
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
May 11 14:36:16 ldapslave00.unix slapd[28265]: [ID 804257 local4.debug] do_syncr
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:


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)