[Date Prev][Date Next]
Re: Delete operation is delayed...
--On Thursday, July 09, 2009 1:36 PM -0400 Rex Roof <firstname.lastname@example.org> wrote:
sorry, it's how I prefer my email. I realize it isn't best for mailing
doesn't that just say that openldap can't properly handle failover, then?
if you're relying on mysql to handle the failover?
I feel like this is way overcomplicating my LDAP setup. I'm dealing with
fewer than 200,000 objects in my LDAP tree, I feel like it should be a
simple thing to provide an adequate failover setup with multiple servers,
all accepting writes, and not relying on one single server to be up for
I'd even be happy with two servers mirroring and other servers slaving
off of them via sync-repl.
I rely on the experts because I don't understand the internals of
OpenLDAP. would you really not suggest using MMR?
if not, why is it an option in the stable release of the code?
The issue you are trying to solve is not unique to OpenLDAP. Any LDAP
implementation has them. Now, like I suggested in a previous email in this
thread, what you probably want is mirror mode and chaining. Mirror-Mode
sets up a single master with a mirrored failover master that will take over
after a heartbeat monitor failure. Setting up chaining on the replicas
causes any modifications made to them to be forwarded to the master. Or,
you could do MMR and chaining, but like any replicated service, updates
will take an unknown amount of time to propogate from any write-accepting
server to the rest of the servers in the pool. That's not OpenLDAP or even
LDAP specific. The *only* way to avoid replication delays is to not use
replication -- which implies back-ndb or a single server (which lacks
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration