[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Delete operation is delayed...

--On Thursday, July 09, 2009 1:36 PM -0400 Rex Roof <rex@wccnet.edu> wrote:

sorry,  it's how I prefer my email.  I realize it isn't best for mailing
list archives.

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



Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration