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. > 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. > 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, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
