Christian Kratzer wrote:
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.
Just posted a patch to ITS#7616. http://www.openldap.org/lists/openldap-bugs/201403/msg00044.html
Try that and see how it goes for you. It should prevent incoming consumer requests if the local database is empty. Otherwise it allows incoming consumers, to avoid the MMR deadlock situation. Aside from that it rejects incoming generic searches while a refresh is in progress.
Greetings Christian