[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: provider/consumer: entries have identical CSN
hi everyone
ok, i think i found it :-). It is the sizelimit parameter on the provider.
'The olcSizeLimit/sizelimit attribute/directive specifies the number
of entries to return to a search request'
Due to the website
http://www.zytrax.com/books/ldap/ch6/
It says that 'If no sizelimit directive is defined the default is
500.' No wonder that i had always 500 results with ldapsearch -x,
despite the fact, that i deleted some entries.
Walter
2013/3/18 Walter Werner <wernwa@gmail.com>:
> hello everyone
>
> I still did not solve my problem, but i think the solution could be
> really some size limitation (already suggested by Marc)
>
> LDAP_RES_SEARCH_RESULT (4) Size limit exceeded
>
> The replication was until Object stud31. So i deleted on provider (on
> the test environment i can do that) Objects stud01 until stud06. And
> the replication went until stud34. 6 deleted and 3 could replicate. I
> guess the other 3 objects where replicated in some other sub trees, i
> did not noticed, if the size-limit is a constant. The question is, is
> there an easy way to see the difference between the provider and
> consumer?
>
> And the main question is, where can the size limitation (if i am
> thinking right) comes from?
>
> Every help is highly appreciated.
>
> Walter
>
> 2013/3/15 Walter Werner <wernwa@gmail.com>:
>> hi Marc
>>
>> Thanks a lot for you quick answer.
>>
>> 2013/3/15 Marc Patermann <hans.moser@ofd-z.niedersachsen.de>:
>>> Walter,
>>>
>>> Walter Werner schrieb (15.03.2013 10:58 Uhr):
>>>
>>>
>>>> I get a strange replication problem. After i didn't find a solution
>>>> somewhere on internet i decided to post to this mailing-list. Probably
>>>> i should describe my system settings. Both consumer and provider are
>>>> running on suse 12.1. And i got the errors with openldap version
>>>> 2.4.26-3.1.3. Since it is a good
>>>> behavior i red somewhere on this email-list, i compiled the latest
>>>> openldap v2.4.34 and could unfortunately reproduce the same error.
>>>
>>> The is a repo, did you know?
>>> http://download.opensuse.org/repositories/network:/ldap:/OpenLDAP:/
>>> (it is still 2.4.33, but anyway)
>>
>> No, i didn't. That can save me a lot of time in the future.
>>
>>>
>>>> Mar 15 09:17:43 ismvm22 slapd[17313]: dn_callback : entries have
>>>> identical CSN uid=stud31,ou=Student,ou=People,ou=myou,dc=mybase
>>>> 20130315072217.081269Z#000000#000#000000
>>>
>>> do the objects differ from provider to consumer?
>>
>> Especially that stud31 object is exactly the same. I am not sure all
>> copied objects are the same, if that was the question. Apparently ldap
>> has added the stud objects in alphabetical order. There are all studXX
>> until stud31. So after stud31 there should be stud32 stud33 and so on,
>> but they are missing on the consumer. It is maybe no accident that in
>> the log it ends with stud31 object.
>>
>> dn_callback : entries have identical CSN uid=stud31...
>>
>>>
>>>> Mar 15 09:17:43 ismvm22 slapd[17313]: do_syncrep2: rid=010
>>>> LDAP_RES_SEARCH_RESULT (4) Size limit exceeded
>>>> Mar 15 09:17:43 ismvm22 slapd[17313]: do_syncrep2: rid=010 (4) Size
>>>> limit exceeded
>>>> Mar 15 09:17:43 ismvm22 slapd[17313]: do_syncrepl: rid=010 rc -2
>>>> retrying (58 retries left)
>>>
>>> Change that!
>>
>> Do you mean Size limit exceeded? I already thought about that. Please
>> look at the partial configs in the first mail.On the provider time and
>> size are set to unlimited for the replicator reader. On the consumer
>> it is also set to unlimited. Maybe i forgot some other option.
>>
>>>> overlay syncprov
>>>
>>> man slapo-syncprov tells more about options to the syncprov overlay.
>>
>> There are indeed a lot more. I tried with additional parameter for checkpoint
>>
>> syncprov-checkpoint 100 10
>>
>> No effect. Other options seems to me for speeding up ldap. I do not
>> want to complicate things. I don't now if it is useful, before trying
>> out something, i also always deleted the database files on the
>> consumer to avoid memory effects of some sort.
>>
>> Still not replicating properly.
>>
>> Walter