(inline) On Wed, Dec 11, 2013 at 02:04:40PM +0100, Marco Nett wrote: > 2013/12/10 Quanah Gibson-Mount <[1][email protected]> > > --On Tuesday, December 10, 2013 11:08 AM -0600 > [2][email protected] wrote: > > Do the slapcat on ldap2 and then delete the db files on ldap1 and then > run > the slapadd. �you will not get duplicates because all of the CSN's > will be > 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 > (ldap1)�slapcat�-l�actual-data.ldiff > Like this? Any traps or common problems I should be aware of? > � > > Huh? > > 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? > > References > > Visible links > 1. mailto:[email protected] > 2. mailto:[email protected]
