On Thursday, 15 April 2010 21:18:13 Tim Gustafson wrote:
Hi,
We have three OpenLDAP servers: 10.0.0.2, 10.0.0.3 and 10.0.0.4 and one web server 10.0.0.5.
How is replication configured? Single master and multiple replicas synchronising off it (which is the master)? MMR or cascading replication (provide a diagram or description)?
If we change
I assume "change" implies restarting slapd ...
the last access clause to this:
[...]
then the user self-updates are replicated properly. Note that 10.0.0.5 is the *web server*. The way I read this ACL, it means we're granting read access to the web server, and in so doing, the other two LDAP servers (10.0.0.3 and 10.0.0.4) are magically able to replicate data again.
So, adding an irrelevant ACL, *and* restarting slapd causes the replication to resume? So, when this occurs, have you tested just restarting slapd?
When replication is *not* working in this set-up, re-starting slapd on 10.0.0.3 and 10.0.0.4 (without changing any ACLs anywhere) causes them to suck down all the updates they missed before.
So, if the ACLs are not modified, but the a restart of slapd forces replication, why would this be an ACL issue(or did I misunderstand this sentence)?
Maybe instead you should post your replication configuration?
Note, there are some still some reliability issues (IMHO) with syncrepl, in that it doesn't always handle connection failures without manual intervention. If these are fixed (I haven't been able to test them myself) in 2.4.x, they are probably still present in 2.3.x. For example, a firewall in between provider and consumer with infrequent changes where the firewall drops idle connections and the hosts have incorrect keepalives set would result in replication failures with refreshAndPersist.
I'm not really asking anyone to fix the problem or to offer a solution to the problem...I just want to know if this sort of replication issue was a known problem in the past?
You don't post anything related to your replication configuration when asking about a replication failure, so it is difficult to provide any more information.
Regards, Buchan