Full_Name: J Version: 2.4.20 OS: Debian/Lenny-AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.67.92.30)
Please clarify this statement in your 2.5 roadmap:
LDAPv3 extensions: *LDAP Transaction support
Do you mean that SyncRepl will actually become legitimately enterprise-class, in that replication will work 100% of the time? Or does this mean transaction support for some other element unrelated to content synchronization?
Why I ask:
I've opened a few tickets on OpenLDAP in the past, related to replication issues involving multiple multimaster servers with a frontend employed (a hardware load balancer) to control writes. From time to time, it seems as though SyncRepl just "decides" to fail, and gives no indication ANYWHERE as to why. We log all sync activity, and we see no indication that the host is unreachable or down, and we see no performance delays when querying the DSAs manually.
* All slapd servers' clocks are perfectly synchronized and are in a common time zone * Of all six multimasters, only two of them actually receive WRITES * All are 2.4.20 on amd64 kernel (Debian Lenny) * We see no discernible improvement when switching from refreshOnly to refreshAndPersist.
Replication will work fine for awhile (in the most recent case, it worked for 16 days, having written test records ranging from 1000 to 50000 *repeatedly* without issues) and then just "fail" ....
We have ruled out the following:
* Bad hardware * slapd Configuration error (have posted our config before) * Firewall timeout issues for cross-site replication (a timeout wouldn't wait 16 days) * Firewall policies between sites (wouldn't cause it to work and then not work). * slapd segfaulting or crashing in some way
This behavior is quite lackluster for a business environment and is ultimately insufficient for any legitimate application. As far as I am concerned, the results are so unbelievably inconsistent that this is an affront to the way SyncRepl is represented/advertised. If it NEVER worked at all, at least THAT would be consistent.
SyncRepl rarely makes any valid attempt to "sync up" when differences are detected between DSAs - SOMETIMES it feels like it, most of the time it does not. I hate to say it, but SyncRepl is a huge pile of misrepresentation and broken promises.
So: Is transaction support intended to SOLVE these issues? If not, maybe you should invent something to replace SyncRepl altogether.
J