Edward Capriolo wrote:
On Thu, Nov 5, 2009 at 5:25 AM, Torsten Schlabach (Tascel eG) tschlabach@tascel.net wrote:
Hi Quanah!
I suggest you go read the CHANGES log for what has been fixed between 2.4.11 and the latest stable 2.4.19.
I need to say, it worries me a bit that for problems with a core feature which has been around for quite some time, the answer is more often that I like to hear: You need to use the latest version released last week / month or so.
I have indeed read the CHANGES and seen that some issues have been fixed. I have no idea if we are affected by those issues or now.
Also how would I know that *now* in 2.4.19 all problems are fixed and the answer next week won't be: You need to use 2.4.20.
But as this is a FOSS project and not a product we pay for, we understand that we should not blame people but try and help if we find a a problem.
For that reason I have asked in my email for help on *understanding* and *diagnosing* problems to have a chance to contribute in case we will find any new issues.
Also our customers may not like it if in case of a problem we tell them: Let's wait if in some weeks a new release will come which will fix it or not. So I'd rather be in a position to get my hands dirty myself in case of problems.
Regards, Torsten
Quanah Gibson-Mount schrieb:
--On Wednesday, November 04, 2009 1:12 PM +0100 "Torsten Schlabach (Tascel eG)" tschlabach@tascel.net wrote:
Hi all!
I am currently trying to chase some problems in an n-way multi-master setup with three servers. We have used the instructions at
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
as our guidance and we are using OpenLDAP version 2.4.11.
I suggest you go read the CHANGES log for what has been fixed between 2.4.11 and the latest stable 2.4.19.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Also how would I know that *now* in 2.4.19 all problems are fixed and the answer next week won't be: You need to use 2.4.20.
Testing reveals the presence of bugs, not the absence :) So no one can every say version x.y.z is certified bug free.
However, I do tend to agree, in that my MM just flaked out, and there is not much load/write/update going on so I am a bit worried.
I am not trying to put down OpenLDAP but iplanet/fedora directory server/389 support up to a 4 way MM implementation and I have found the replication rock solid even under high load. So if MM is your requirement that may be a more valid option.
The historical evidence disagrees with your assertion. Even at this late date, FDS MMR still breaks irrecoverably.
https://www.redhat.com/archives/fedora-directory-users/2009-November/msg0005...
How many years have they been flogging this feature? They still haven't got it right. They can't.
MMR is inherently flawed, as we have been saying for years.
http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt
We have implemented it in OpenLDAP mainly for political reasons, not because we changed our minds and now believe it to be technically sound. It is not. We developed and recommend MirrorMode because the only safe way to do replication is by preserving single-master consistency.
The answer is quite simple: do not use multimaster replication in a production environment. In most cases the requirement for multimaster replication is just based on poor directory design.
Dieter, I do not agree with that. You can't blame a user for using a feature. It is not marked as experimental anymore so people are going to use it. Once it fails you can't call them a "Poor Directory Designer" for using it.
If they have implemented MMR without reading all of the warnings, they are certainly poor designers for not becoming fully informed of the topic before deploying it. If they have implemented MMR after reading all of the warnings, they made a conscious choice.