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

Re: 2.2 -> 2.3: syncproc, syncrepl production quality?

At 02:48 PM 5/24/2006, Quanah Gibson-Mount wrote:

--On Wednesday, May 24, 2006 2:04 PM -0700 Jed Donnelley <jed@nersc.gov> wrote:

Hello Openldap,

I currently have an openldap configuration with a master server running
opendlap 2.2.29 and slaves running 2.2.23, 2.2.24, 2.2.28, and 2.2.29 (5 replicas total
on systems under various administrative controls).

Getting the following error:

May 24 13:21:42 sbuild3 slapd[8127]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1

Did you load the syncprov overlay, as is required in 2.3?

Thanks. That was the key to my problem. Once I started down that path I ran into a number
of problems that I eventually found others had run into. E.g. when doing the make config
for openldap23-server it was important not only to turn on SYNPROV, but also to turn
<off> SHELL. If SHELL is left on (the default) then threading is turned off resulting in:

/libexec/ld-elf.so.1: /usr/local/lib/libldap_r-2.3.so.2: Undefined symbol "pthread_getconcurrency"

I'll note you probably want to be running 2.3.23, there were a number of syncrepl related bug fixes since 2.3.21 was released.

I also made the above update per your suggestion. That update ended up updating much of
the world (bdb, perl, x11, ...), but other than that and the issues with SYNPROV it went
pretty smoothly. My configuration:

2.2.29 Master production ldap ----> 2.3.23 Slave | Master sbuild3 -----> 2.2.30 Slave sbuild5
| \
existing replicated slaves

now seems to be working with syncprel (refresh-only) happening at both levels.


One thing concerns me a bit. When we first started using syncrepl openldap was at 2.2.28.
Things worked - sort of. We had occasional hangs. We heard that the upgrade to 2.3
was motivated partly to fix up problems with syncrepl. So 2.3 came out and went through
various revisions and we're now up to 2.3.23. However, if you say that "a number of
ryncrepl related bug fixes" were fixed in 2.2.23 since 2.2.21 was released, doesn't that
suggest that syncrepl is still a bit unstable? Is this production quality code?

I'm wondering if we shouldn't switch our production services back to slurpd until syncrepl
is production ready? Switching back all our replicas would be a real pain, so I'm willing
to try just upgrading the master and then even upgrading the replicas one at a time if needed.
However, if we still have problems then I'm thinking that we might be better off going
back to slurpd.

Does anybody else have any experience to share regarding the production quality of
the sync-repl code?

--Jed http://www.nersc.gov/~jed/