[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
- From: hyc@symas.com
- Date: Wed, 14 Aug 2013 23:01:59 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
hyc@symas.com wrote:
> Michael Ströder wrote:
>> hyc@symas.com wrote:
>>> I was considering returning LDAP_BUSY for this case, but it may make more
>>> sense to return a REFERRAL to the provider instead. (Although again, if we
>>> have two MMR servers pointed at each other starting at the same time, they
>>> would just refer to each other and clients would get nowhere until one of them
>>> finishes its refresh.)
>>
>> IMO referrals are harmful.
>> Just returning LDAP_BUSY seems best to me because if reliable HA is really
>> important for a deployment you have decent load-balancers in front of your
>> LDAP server which should do a proper health-check.
>
> Agreed.
>
>> Just a question: Is this database-specific? Maybe only one of several DBs is
>> in this initial syncrepl phase and access to others should simply work.
>
> Overlays are db-specific.
>
A similar feature was already implemented, and never documented:
commit 9e00b6cc6ce2857490b33218bdaf1339319c5f60
Author: Howard Chu <hyc@openldap.org>
Date: Fri Apr 15 11:13:38 2011 -0700
Add strictrefresh syncrepl option
Only affects delta-syncrepl - stop listening to clients while
refresh is running.
This is a bit more extreme though, it terminates all client connections and
suspends the slapd listeners while a refresh is running. The solution
discussed in this ITS would be preferable.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/