On 12/17/25 11:23 AM, Ondřej Kuzník wrote:
On Wed, Dec 17, 2025 at 10:16:11AM -0500, Brendan Kearney wrote:
The "just start with an empty DB" option is what I am looking for, but in my
past upgrades (years and versions ago) this did not seem to work. Only some
entries wound up on the newly built server. I wound up stopping other
instances and copying over the .mdb file in the DB directory and restarting.
Are you sure the identity also had limits (size especially) set to
unlimited? Or see below which is just as likely.
I don't have any explicit size limits on identities. DB size limits are
"unlimited" for cn=config, 25 GB on DIT.
Since I will be reusing the SID associated with each server, will attributes
written by SID 3 not be copied over to the newly built server 3, that has
SID 3? This seemed to be one of the nuances I saw, though I could be
flat-out wrong. Maybe I was just impatient and did not wait long enough for
the replication to complete.
Reusing serverids is a misconfiguration, each provider **has** to have a
unique non-zero serverID. The replication logic relies on it to decide
where changes are coming from and where (not) to route them. This is why
the serverID option has a second form of "serverID <id> <listen URL from
slapd -h ...>" so that you can replicate cn=config but have every server
maintain its own identity.
Everyone else apart from providers can keep their serverid at default
(="0") but they can also have one assigned if you want to be able to
promote them to providers easily, your choice.
so, the olcServerID and rid used in the replication configs should both
be incremented when rolling over / upgrading a box?
It was one of those odd things that I saw when upgrading. Some data was
replicated, and the .mdb file was vastly smaller on the newly built box and
there did not seem to be traffic going between the existing cluster members
and the newly built one, indicating that replication was still updating the
new instance. If it was my impatience, would you know how long it takes for
the replication to fully populate the blank DB? My current DB is about 2.5
GB in size.
Yes, see above. If a server claiming its serverid was 3 talked to
another provider, that provider would make sure not to route any change
tagged as coming from sid 3 back to it. It should have been the one to
have originated it in the first place so doing otherwise is wasteful or
worse.
Regarding the DB size and time to replicate: depends on your storage
speed/latency. If you can write 1000 new entries/s, then I would expect
a DB with 3.6M entries will take roughly an hour to finish syncing from
scratch?
Also run with loglevel stats,sync and watch your logs for errors if you
don't trust your cluster yet, and there's always cn=monitor too[0]. I
would note that 2.7 should also get a little better at logging
replication activity.
[0].
https://lists.openldap.org/hyperkitty/list/[email protected]/thread/2FIU5G5ZDR522TXF2FNZZV5H3YZ4ZN5Z/
Regards,
