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
- 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.