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

Re: Delete operation is delayed...

Rex Roof wrote:
> Gleaning any information out of that list is an arduous process.   A
> short description of each of those ITS bugs in the CVS comments would
> serve that changes list well.

$ grep -i "mmr" CHANGES
        Fixed slapd syncrepl too many MMR messages (ITS#6020)
        Fixed slapd syncrepl skipped entries with MMR (ITS#5988)
        Fixed slapd-syncprov too many MMR messages (ITS#6020)
        Fixed slapo-syncprov skipped entries with MMR (ITS#5988)
                admin24 clarified MMR URI requirements (ITS#5942,ITS#5987)
        Fixed slapd glue with MMR (ITS#5925)
        Fixed slapd syncrepl MMR when adding new server (ITS#5850)
        Fixed slapd syncrepl MMR with deleted entries (ITS#5843)
        Fixed slapd syncrepl MMR partial refresh (ITS#5470)
        Fixed slapd-bdb MMR (ITS#5332)

Now this line seems relevant to the issue of the original poster:

        Fixed slapd syncrepl MMR with deleted entries (ITS#5843)

So what's wrong with the CHANGES file?

> but as an
> administrator of OpenLDAP it is really frustrating to read about
> Multi-Master Replication and to have people make random comments on the
> mailing lists about MMR being dangerous and to read 5 year old papers
> about how harmful it is (
> http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt )
> but yet the OpenLDAP 2.4 docs don't really warn against using it.

That's a completely different issue and it has nothing to do with which
LDAP server implementation you're using. The I-D above is worth reading.
Hope you did and understood it.

> How are we supposed to be setting up OpenLDAP servers so that we can
> have failover?

That depends entirely on your deployment. Note that in general not your
OpenLDAP server does the fail-over. Your LDAP clients have to do the
fail-over or a component in front of your servers. Whether that really
works depends on the characteristics of read/write operations sent by
your LDAP client applications.


If you're just doing single write operations and all your LDAP clients
are doing simple logins with some password changes here and there you
don't have to worry about doing multi-master replication. You might
loose a write operation when one server is going down. But you won't
loose data integrity.

If you have LDAP client applications which sends a bunch of interrelated
writes or it's immediately reading the written content after writing you
will have a lot of weird issues even in cases where everything's fine.
Not to speak of some of the writeable servers going down without the
application really noticing and acting upon it.

=> As always you have to carefully think about *your* deployment.
There's no simple rule-of-thumb which fits every scenario. Being able to
design something like this in a robust manner distinguishs good IT
architects from bad IT architects.

>  I want to have a half-dozen OpenLDAP machines and have
> any one of them accept writes and not be relying on any one of them to
> be up for writes to occur.  I've asked this question numerous times and
> haven't ever gotten a reliable answer.

It would be grossly negligent to give a simple answer to such a
question. You should appreciate when people give you a hint that things
might be more complicated than you thought.

> It is starting to get really annoying.

Well, if you're not willing to think yourself you have to buy skilled
people for analyzing/designing your architecture.

Ciao, Michael.