We've started experiencing syncrepl replication issues recently that look
like this in the logs:
syncrepl_entry: rid=011 be_search (0)
syncrepl_entry: rid=011 uid=example,ou=People,dc=foo,dc=bar
syncrepl_null_callback : error code 0x7a
syncrepl_entry: rid=011 be_modify uid=example,ou=People,dc=foo,dc=bar (122)
We have a 3 node multi-master/provider cluster that we recently upgraded
from 2.6.10 to 2.6.13.
We've been using the Symas packages, on Debian 12, FWIW.
Our config uses simple syncrepl (not delta-syncrepl). We replicate both
cn=config as well as our main base dn.
Upon upgrading to 2.6.13, we faced an initial hiccup because the symas
packages transitioned to use the OS provided cyrus sasl libraries, which
meant the sasl config file changed locations. Once we sorted that out
things seemed to be functioning properly. I should have checked the
changelog on the package.
As a practice we make all ldap entry updates/additions/modifications via
one designated "primary" cluster member. My initial attempt to resolve the
issue involved reloading the db on the two "non-primary" nodes from a
slapcat from the "primary" node. This seemed to fix the replication issue
(I could make changes via our primary node and they'd replicate properly to
the other nodes), however a day later I'm noticing that replication has
stalled out again.
Does this sort of issue ring any bells for anyone? At first glance I don't
see anything in the CHANGES file between v2.6.10 and v2.6.13 that would
trigger this issue, but I'm certainly not an expert. Our cluster has been
performing flawlessly with the 2.6 branch for several years now, so this is
a bit disconcerting.
Ben
--
Ben Poliakoff <benp(a)reed.edu> - Technology Infrastructure Services - Reed
College
