On 12/17/25 9:46 AM, Ondřej Kuzník wrote:
On Wed, Dec 17, 2025 at 09:18:04AM -0500, Brendan Kearney wrote:
List members,
I plan on updating my 3 node multi-primary instances and want to have a full resync done when each instance is rebuilt and rejoined to the cluster. Currently, I have both config and DIT fully replicated between all instances. When I rebuild each node, it will have all of the configs in place to be a part of the cluster. What I would like to have is all the data pushed to the newly built, but empty, instance.
I have a process that is somewhat brute force, where all data is exported, stripped of entryCSN and contextCSN values, then added back to the newly built instance. This would require that the other instances be stopped or otherwise not take any updates during the transition. I would like to avoid this disruption in service, if at all possible.
Is there a way to have a full resync done when a rebuilt instance that has no data rejoins a cluster?
Hi Brendan, it's much simpler than you think:
- slapcat cn=config, slapadd -n0 it on each server
- then either:
- slapcat your DB(s) on one of the servers, then just slapadd it (no changes, no behavioural options, maybe -q)
- or just start with an empty DB and the replica will sync up from scratch, when it does, you can register it with your load balancer
Certainly do not munge the slapcat output in any way before loading it. The slapcat is also your backup, some sites choose to set up a spare server that gets stopped, slapcat'd and then started again. Gives them a pristine backup as well with no impact on the rest of the site.
Just to make sure:
- check your ACLs are up to scratch - give the replicating identity **full and unrestricted** read access to the relevant DB
- that each server resolves its unique serverID correctly
- monitor your replication (e.g. with syncmonitor[0] or a homegrown tool)
[0]. https://git.openldap.org/openldap/syncmonitor
Regards,
Ondrej,
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.
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.
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.
Thank you,
Brendan Kearney