[Date Prev][Date Next]
Re: some questions about syncrepl
Quanah Gibson-Mount skrev, on 09-10-2007 11:06:
And you didn't replied to my actual question: among the four kind of
syncrepl usage (delta vs total, search and persist vs refresh only), are
some of them more robust than others ?
delta-syncrepl has been the most stable for me, although I believe the
final issue I had seen in normal syncrepl will be fixed in the upcoming
2.3.39 release. What I'm trying to point out to you, is that several
*known problems* with both syncrepl and delta-syncrepl have been fixed
since the 2.3.27 release. No developer is going to want to waste the
time trying to help you with an issue that's likely already solved, and
certainly the symptoms you've described remind me of issues I had in
Using my newly repaired crystal ball, I'd guess that many people
doggedly holding on to 2.3.27 are most likely using RHEL5 or CentOS5 and
scared of going outside of the latters' update frames.
Whilst Red Hat claims to backport version improvements it's pretty
obvious that its policy for OpenLDAP is confined to fixing security
bugs. When RHEL5 was introduced with OL 2.3.27 it was a relatively
recent release and I decided to try it instead of Buchan's up to date
stuff. It's basically flawed in that it doesn't allow the module
flexibility that Buchan's does and maybe in other ways. Certainly delta
syncrepl doesn't work as it is supposed to.
My high school site runs an OL 2.3.33 delta syncrepl provider and 3
2.3.37 refresh and persist consumers, it's utterly stable 24x7 (highest
uptime is 17 days because of new-kernel reboots but with the obsolete
RHEL4 there were uptimes of scores of days) and does everything it's
supposed to, including chaining from one of the slaves. Yes, there's a
reason I'm sticking to 2.3.33 on the provider for the time being.
Email: tonni at hetnet dot nl