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.