Howard Chu wrote: > 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. If you have HA requirements in such a replication setup you will set up another replica with such a configuration => see "set of databases" in item 1. above. >> 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. Thinking is always good. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature