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