Restarting this thread...
we have had some interesting discussion today that I wanted to share.
Hypothesis : 1 server has been down for a long time, and the contextCSN is older than the one of the other servers, forcing a refresh mode with more than the content of the AccessLog.
Quanah said that in some heavily servers, the only way for the consumer to catch up is to slapcat/slapadd/restart the consumer. I wonder if it would not be a way to deal with server that are to far behind the running server, but as a mechanism that is included in the refresh phase (ie, the restarted server will detect that it has to grab the set of entries and load them, os if a human being was doing a slapcat/slapadd/restart).
More specifically, is there a way to know how many entries we will have to update, and is there a way to know when it will be faster to be brutal (the Quanah way) compared to let the refresh mechanism doing its job.
Another point : as soon as the server is restarted, it can receive incoming requests, which will send back outdated response, until the refresh is completed (and i'm not talking about updates that could also be applied on an outdated base, with the consequences if there are some missing parents). In many cases, that would be a real problem, typically if the LDAP servers are considered as part of a shared pool of server, with a load balance mecahnism to spread the load. Wouldn't be more realistic to simply consider the server as not available until the refresh phase is completed ?
Thanks !