[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 past releases.

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.



Tony Earnshaw
Email: tonni at hetnet dot nl