Re: canonical way to force full refresh in 2.4.28 / n-way multimaster

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Thursday, February 16, 2012 2:23 PM -0500 Aaron Bennett 
<abennett@clarku.edu> wrote:

> Hi,
>
>
>
> I'm preparing to rollout 2.4.28 with n-way multimaster (in this case,
> it's really 2-way multimaster but could become more), and I'm looking
> to clarify what the exact canonical way to force a full refresh.
> Here's what I've come up with:

First, I would *strongly* advise you to download 2.4.29 plus the following 
patches, as they fix issues with Syncrepl, since I'm guessing you are not 
using delta-syncrepl based MMR.

<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=8e7af6331ec2d0edaeb203b1c52d4016bc2bbcbf>

<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=d4b3c2af6a61678060ef417b59bd63a36ec15c13>

<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=eace24ef33dfae071b9450866d0ef5b0d3ad6d7f>


> By "full refresh" I mean, blow away whatever is on machine Y with
> whatever's on machine X.
>
>
>
> olcServerID: 1 ldaps://animal.clarku.edu
>
> olcServerID: 2 ldaps://zoot.clarku.edu
>
>
>
> olcSyncrepl: {0}rid=001 provider=ldaps://animal.clarku.edu binddn="DN OF
> REPLICATION USER" bindmethod=simple credentials=<PASSWORD>
> searchbase="dc=clarku,dc=edu" type=refreshAndPersist retry="5 5 300 5"
> timeout=1
>
> olcSyncrepl: {1}rid=002 provider=ldaps://zoot.clarku.edu binddn="DN OF
> REPLICATION USER " bindmethod=simple credentials=<PASSWORD>
> searchbase="dc=clarku,dc=edu" type=refreshAndPersist retry="5 5 300 5"
> timeout=1
>
>
>
> 1.       Stop slapd on zoot.
>
> 2.       slapcat > ocrap-backup.ldif
>
> 3.       rm ârf /var/lib/ldap/* on zoot
>
> 4.       SLAPD_OPTIONS="-c \"rid=001,sid=001\"" /etc/init.d/slapd
> start
>
>
>
> Then wait and it will refresh.
>
>
>
> Is this correct? Is there some easier way?  Is there a way to do it
> without the rm ârf ?  After it's done, do I need to restart slapd
> again without the âc option?

You definitely have to do the rm -rf to remove the old DB.  I would 
suggest, however, that you just slapcat the other master and load the data 
in to your the one you are updating, that will significantly reduce the 
time to sync.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration