On Wed, Dec 11, 2013 at 02:04:40PM +0100, Marco Nett wrote:
2013/12/10 Quanah Gibson-Mount <quanah(a)zimbra.com>
--On Tuesday, December 10, 2013 11:08 AM -0600
Do the slapcat on ldap2 and then delete the db files on ldap1 and then
the slapadd. �you will not get duplicates because all of the CSN's
the same. �This is what I have done my migrations to the most recent
versions and doing my own builds. �Works great that way.
Trying not to sound too obtuse, but still not grasping something about this thread.
The last time I had a master of a multimaster pair stay down for a while I just turned the
long-halted master back on. Eventually syncrepl did its thing. I ldapsearch'd
corresponding databases on both hosts, sorted/diffed the outputs and found no differences
in the output (both masters had the same data).
So what's the difference between waiting for syncrepl and going to all the effort that
people are describing?
So by "delete the db files" you mean deleting the
contents of the slapd
home-dir (usually /var/lib/ldap)?
Here's what I read out of your answer:
(ldap2)�slapcat -bcn=config -l config.ldiff
(ldap2) slapcat -l actual-data.ldiff
(ldap1) rm -rf /var/lib/ldap/*
(ldap1) /etc/init.d/slapd start
(ldap1)�slapadd -bcn=config -l config.ldiff
Like this? Any traps or common problems I should be aware of?
The CSNs contain the server IDs. �Servers ignore their own changes.
You're saying I shouldn't delete the files before doing the cat/add
business, right? If I'd do it like this, wouldn't stuff that got deleted
on ldap2 (while ldap1 was down) still end up being on ldap1?