The "reload" process that I've followed is the same sort of thing that I'd do if I were standing up a new cluster node:

1. grab a backup from the primary node (slapcat output of the base DN for the directory)
2. shut down slapd on the node that's to be "reloaded"
3. move aside the data.mdb and lock.mdb files on the node that's being "reloaded"
4. repopulate the db on the node that's being "reloaded" via slapadd, using the backup slapcat dump mentioned above
5. start slapd

After the above process, the "reloaded" node generally catches up pretty quickly with the primary node (observed by watching contextCSNs sync up across the cluster). I haven't had to reload them again, since I wrote my initial post to this list, but I have had to restart slapd on the non-primary nodes twice, after watching contextCSNs go out of sync.

All of this is a new issue for me, we've run openldap in a variety of configurations, and this particular configuration has been very reliable for 3 or 4 years now, so I'm puzzled.

Ben


On Thu, Jul 2, 2026 at 11:55 PM Windl, Ulrich <u.windl@ukr.de> wrote:

Hi!

 

Maybe explain how you did “reload” your DB exactly (just in case).

 

Kind regards,

Ulrich Windl

 

From: Ben Poliakoff <benp@reed.edu>
Sent: Wednesday, July 1, 2026 11:40 PM
To: openldap-technical@openldap.org
Subject: [EXT] Issues with syncrepl replication potentially since update from 2.6.10 to 2.6.13

 

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@reed.edu> - Technology Infrastructure Services - Reed College