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
