Re: Delete operation is delayed...

[Michael Ströder <michael@stroeder.com>]

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.

Examples:

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.