5:04 a.m.
2013/12/10 Quanah Gibson-Mount <quanah(a)zimbra.com>
--On Tuesday, December 10, 2013 11:08 AM -0600
espeake(a)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?
7:27 a.m.
New subject: Recovering from a Single-Node downtime in a Multi-Master Setup
(inline)
On Wed, Dec 11, 2013 at 02:04:40PM +0100, Marco Nett wrote:
2013/12/10 Quanah Gibson-Mount <[1]quanah(a)zimbra.com>
--On Tuesday, December 10, 2013 11:08 AM -0600
[2]espeake(a)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
1. mailto:quanah@zimbra.com
2. mailto:espeake@oreillyauto.com
8:21 a.m.
New subject: Recovering from a Single-Node downtime in a Multi-Master Setup
--On Wednesday, December 11, 2013 10:27 AM -0500 Christopher Wood
<christopher_wood(a)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(a)zimbra.com>
>
> --On Tuesday, December 10, 2013 11:08 AM -0600
> [2]espeake(a)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
3464
days inactive
3464
days old
openldap-technical@openldap.org
2 comments
3 participants
participants (3)
-
Christopher Wood -
Marco Nett -
Quanah Gibson-Mount