[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP syncrepl woes
On Thu, Nov 17, 2011 at 11:47 PM, Howard Chu <hyc@symas.com> wrote:
> Jeffrey Crawford wrote:
>>
>> On Thu, Nov 17, 2011 at 9:21 PM, Howard Chu<hyc@symas.com> wrote:
>>>
>>> Jeffrey Crawford wrote:
>>>>
>>>> On Thu, Nov 17, 2011 at 5:50 PM, Howard Chu<hyc@symas.com> wrote:
>>>>>
>>>>> There ought to be other error messages in your log, immediately
>>>>> preceding
>>>
>>>>> the one you quoted. Post those too.
>>>
>>>> There really isn't much there but here is an example really not much
>>>> around it: (I've modified the usernames only)
>>>>
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10706 DEL
>>>> dn="uid=user1,ou=people,dc=ucsc,dc=edu"
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10706 RESULT
>>>> tag=107 err=0 text=
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10707 DEL
>>>> dn="uid=user2,ou=people,dc=ucsc,dc=edu"
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10707 RESULT
>>>> tag=107 err=0 text=
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10708 DEL
>>>> dn="uid=user3,ou=people,dc=ucsc,dc=edu"
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10708 RESULT
>>>> tag=107 err=0 text=
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10709 DEL
>>>> dn="uid=user4,ou=people,dc=ucsc,dc=edu"
>>>> Nov 17 21:11:55 localhost slapd[1912]: bdb(dc=ucsc,dc=edu): previous
>>>> transaction deadlock return not resolved
>>>> Nov 17 21:11:55 localhost slapd[1912]: => bdb_idl_delete_key: cursor
>>>> failed: Invalid argument (22)
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10709 RESULT
>>>> tag=107 err=80 text=entry index delete failed
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10710 DEL
>>>> dn="uid=user5,ou=people,dc=ucsc,dc=edu"
>>>> Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10710 RESULT
>>>> tag=107 err=0 text=
>>>
>>> Strange. The log shows an error occurring while deleting an index. The
>>> error
>>> message indicates that there was already a deadlock before, but there's
>>> no
>>> message from the original deadlock, and the indexing code logs *every*
>>> error
>>> that occurs. Seems more likely a BDB bug.
>>>
>>> Also your client is broken, it looks like it completely ignored the
>>> failure
>>> result from the ldapdelete operation, it just went right on to issue
>>> another
>>> request.
>
>> ldapdelete was using the -c option so it just continued I've actually
>> was able to replicate the error on a small local installation using
>> the default openldap install. When I changed it to BDB 4.8 I've yet to
>> see the error. So I'm going to run this a few more times and see if it
>> does indeed fix things.
>>
>> Fingers crossed
>
> Sounds promising. Looking forward to your conclusion.
>
> Of course, with back-mdb, none of this type of nonsense can ever happen...
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
Things look pretty good since going to bdb 4.8. However for future
reference, what is the best way to force a replica to simply discard
what it has and reload from the provider ldaps. So far all I can do is
remove the database and restart. However this means any record it has
yet to see is not available until the replica get to that record. I
would rather re-sync in such a way that it looks at each records and
re-updates or deletes if it cant find the original record on the
provider server.
Starting slapd with the -c option isn't working or I'm using the wrong
combination.
Thanks
Jeffrey