2013/12/10 Quanah Gibson-Mount quanah@zimbra.com
--On Tuesday, December 10, 2013 11:08 AM -0600 espeake@oreillyauto.comwrote:
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.
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?
(inline)
On Wed, Dec 11, 2013 at 02:04:40PM +0100, Marco Nett wrote:
2013/12/10 Quanah Gibson-Mount <[1]quanah@zimbra.com>
--On Tuesday, December 10, 2013 11:08 AM -0600 [2]espeake@oreillyauto.com 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
- mailto:quanah@zimbra.com
- mailto:espeake@oreillyauto.com
--On Wednesday, December 11, 2013 10:27 AM -0500 Christopher Wood christopher_wood@pobox.com wrote:
(inline)
On Wed, Dec 11, 2013 at 02:04:40PM +0100, Marco Nett wrote:
2013/12/10 Quanah Gibson-Mount <[1]quanah@zimbra.com>
--On Tuesday, December 10, 2013 11:08 AM -0600 [2]espeake@oreillyauto.com 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?
Speed? If you have a large database, waiting on syncrepl is going to take forever.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Christopher Wood -
Marco Nett -
Quanah Gibson-Mount