On Fri, Sep 03, 2010 at 04:35:24PM +0200, Jonathan CLARKE wrote:
DB_LOCK_DEADLOCK errors are only a warning: retries should occur until the operation completes. Of course, if they can be avoided, best avoid!
Question: is this topology sensible? If it is expected to work I will gather some debug data for an ITS. If not, I will have to drop back to plan B...
This is an interesting configuration. I would not have proceeded like this but, as Marc Patermann suggested, I would set up a virtual address that points to the currently available master, and configure one syncrepl clause using this address (and all other LDAP clients, in fact). Could this approach work for you?
That is what I have done now, and it does work. I am still a little uncertain about it though: when the normal server fails and the DNS entry or routing changes to point to the hot standby, will this confuse the consumer slapd? We are effectively telling it that the second machine *is* the original one, yet it will have a different serverID and possibly different contents.
Looking at the OpenLDAP configuration issue, I note your remark that several syncrepl statements are used in multi-master setups. I'm not entirely sure why this works better, but it may well be due to all servers having the syncprov overlay, which serializes modifications when a persistent search is in progress.
Sounds plausible.
Using two syncrepl statements is certainly suboptimal, as all modifications will be replicated twice to all read-only servers. However, I don't see any reason why it shouldn't work, off the top of my head. Does slapd end up synchronizing everything?
Not sure - there were only 25000 entries but I gave up and stopped the consumer server after 30 minutes as it still had not synchronised.
Good point about the double replication, though if it had worked cleanly it would be OK in the (low modification) environment that I have. The advantage is that nothing else is needed to manage the failover / fail-back cases.
Andrew