[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Denying access to syncrepl consumere during initial DIT content load
Hi,
On Mon, 24 Mar 2014, Michael StrÃder wrote:
Howard Chu wrote:
Christian Kratzer wrote:
I remember a discussion some time ago about the possibility of delaying
access to a syncrepl. consumer during the intial DIT load.
http://www.openldap.org/lists/openldap-bugs/201308/msg00043.html
Feel free to experiment with it and see whether it suits your need.
Why was this undocumented strictrefresh option limited to delta-syncrepl?
ok Thanks for the pointer.
Thats why it is not working in my setup as this old horse still does regular syncrepl....
I see following in servers/slapd/syncrepl.c
1013 if (si->si_strict_refresh) {
1014 slap_suspend_listeners();
1015 connections_drop();
1016 }
and folloing turns listeners on later on:
1174 if ( err == LDAP_SUCCESS
1175 && si->si_logstate == SYNCLOG_FALLBACK ) {
1176 si->si_logstate = SYNCLOG_LOGGING;
1177 rc = LDAP_SYNC_REFRESH_REQUIRED;
1178 slap_resume_listeners();
1179 } else {
1180 rc = -2;
1181 }
The logic seems to be that once we are synced up with one of the providers we should be set as the other providers should have identical data.
I can also see the next caveat that resetting all connections is possibly triggered each time a syncrepl connection is setup to a provider. Perhaps even when dumping connections on a consumer when a provider is restarted and the consumer reconnects.
I would really like such a feature for consistency but this seems to need more deep thinking.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/