[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Denying access to syncrepl consumere during initial DIT content load

Michael Ströder wrote:

Howard Chu wrote:

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?


Just expedient at the time, it would take more code to cover other cases. Also
it wasn't clear to me that this was actually a good approach, thus the need
for other developers to test it and give feedback.


Hmm, it's some work and risk to change a serious setup to delta-syncrepl.


The biggest problem with this approach is that it has global impact - turning
off slapd's listeners. On a slapd with multiple independent databases, this
would be a bad idea.


IMO that's not really an issue because
1. you likely have many replicas serving the same set of databases to clients and
2. it's very likely that you're initializing all DBs at once because if
deploying a new server, recovering after file system corruption etc.
An obvious counter-example: a server with multiple databases, consuming from distinct providers. If the connection to one of those providers is lost and reconnected, the current code would disable slapd globally but only one of the multiple DBs needs to be blocked. 


Anyway having an slapd-internal mechanism is way better than external
work-arounds with monitoring contextCSN and using iptables etc.
Sure. But again, it requires more thinking, there are plenty of undesirable side-effects to any approach you can mention. 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/