[BSD] openldap syncrepl "size limit exceeded"

[Péchy Gáspár]

On 2011.10.17. 23:42, Gabor HALASZ wrote:
> On 10/17/2011 10:38 PM, Péchy Gáspár wrote:
>> On 2011.10.17. 21:59, Gabor HALASZ wrote:
>>> On 10/17/2011 9:22 PM, Péchy Gáspár wrote:
>>>>>
>>>>> Sizelimit 0-val meg dehatabb :)
>>>> sizelimit 0-át még nem ettem, ha műkszik (s ha kell), mindenképp
>>>> elegáncsosabb
>>>
>>> Egy ideje:
>>>
>>>          sizelimit {<integer>|unlimited}
>>>
>>> de a 0 is jo szokott lenni. Valahol (altalaban nem globalisan) de
>>> szukseg lesz ra (hacsak nem tudod elore meghatarozni az adatbazis
>>> meretet), hogy a szinkronizacio ne akadjon el.
>>>
>>>>>
>>>>>> #limits dn.exact="cn=neddugi,ou=mydep,o=firm" size=unlimited
>>>>>> time=unlimited
>>>>>
>>>>> Nekem ehhez hasonlo mukodik, csak komment nelkul :) Kellene a syncrepl
>>>>> konfiguracioja, mert ebbol sok minden nem latszik.
>>>> Íme:
>>>>
>>>> syncrepl rid=001
>>>>       provider=ldap://mydomain.hu:389
>>>>       type=refreshOnly
>>>>       interval=00:00:00:10
>>>>       searchbase="ou=mydep,o=firm"
>>>>       filter="(objectClass=*)"
>>>>       scope=sub
>>>>       bindmethod=simple
>>>>       binddn="cn=neddugi,ou=mydep,o=firm"
>>>>       credentials=neduddmeg
>>>>
>>>
>>> Erre pedig illeszkedik a fenti (kikommentezett) limit. Van egy-ket
>>> tippem, hogy mivel tudod megkeresni a hibat (elso korben egy ldapsearch
>>> a fenti dn-nel, mikozben a slapd loglevelje tartalmazza a 128-at), ha
>>> csak megoldast akarsz, akkor tedd ide a sizelimit unlimited-et, akkor
>>> csak a syncreplre vonatkozik. Mellekesen nem sok ertelmet latom
>>> 10s-enkent refreshonly-zni, ha ilyen gyakran valtozik a db, akkor jobb a
>>> refreshandpersist.
>> Köszönöm az infót, kipróbálom a masteren 128-al; Próbáltam a replica
>> oldalon limits=nnn-t, az nem működött, kipróbálom ugyanott sizelimittel,
>> az lenne a legideálisabb, de az (eddíg olvasott) irodalom szerint a
>> master (ha szűkebb) a mértékadó.
>
> Nem tudom, mit olvastal, de nekem kicsit gyanus, hogy outdated, mert
> syncrepl-nel consumer es provider a terminologia, nem master es replica.

Későre jár, s mysql replikáció is van a környezetben :)

> Amit irsz, az eleg elnagyolt kovetkeztetes. A slapd annyi adatot
> szolgaltat, amennyit a sizelimit enged. Ha globalis a sizelimit, akkor a
> replikacio soran csak az adatbazis egy resze kerul at a masik gepre,
> amit barmekkora lehet a sizelimit, csak egy reszevel rendelkezik a
> teljes adatbazisnak (de az legalabb inkonzisztens lesz). Abban nem
> vagyok biztos, hogy syncrepl eseten egyaltalan letrejon-e valami, vagy
> rollbackel az utolso checkpointhoz. Itt olvasgass:
>
> http://www.openldap.org/doc/admin24/guide.html#Replication

Jah, képben van a http://www.openldap.org/doc/admin24/limits.html-lel együtt.
Új consumer lesz, (s scratch-ből akartam felállítani) ezért a nagyobb adattömeg amivel a sizelimitbe 
ütköztem, a régi rendszer - provider-consumer - rendben megy. A "master a mértékadó (értsd: 
provider)"-val arra céloztam, ha a provider sizelimitje 500, feltehetően hiába adok a consumeren 
bármekkora értéket, avagy unlimitedet, a provider akkor sem fog 500-nál többet engedni.

Lényeg a lényeg, hogy a témánál maradjunk: a limits "dn.." verziónak, menni kéne (elvben), de nem 
mén - mindenképp megnézem az ajánlott loglevellel egy helyi ldapsearch eredményét valahol máshol, az 
élőn túl nagy a forgalom a loglevel 128-hoz (az autentikációk LDAP-on vannak).
>
> Gyakorlatban nem szokott problemat jelenteni a globalis unlimited sem,
> mert nem no akkorara a db, hogy szamottevo terhelest okozna akar az
> egeszet letolteni (ugyis igyekszik a memoriaban tartani), tobb problemat
> okoz pl a default engedelyezett anonymous bind.
>
>> A 10 sec inkább azért került annó bele (emlékeim szerint) mert : a./
>> noob vagyok  b./ha változna, lehetleg gyorsan "mentse" a változást.
>> Egyébként tényleg elég lesz ritkábban, kösz.
>
> Ha nincsen valami nyomos okod erre a felallasra, akkor mirrormode-dal
> probalkozz inkabb, a fenti linken van example.

Ez még emésztésre szorul :)

Üdv,
Gazsi
>