[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: MDB data replication issues



--On Wednesday, June 29, 2016 4:21 PM +0200 Bastian Tweddell <b.tweddell@fz-juelich.de> wrote:

On 27Jun16 09:16-0700, Quanah Gibson-Mount wrote:
--On Monday, June 27, 2016 2:00 PM +0000 Gurjot Kaur
<gurjot.kaur@aricent.com> wrote:

> Thanks Bastian for your response.
>
> But I want to clear that I don't use slapadd while slapd is running. I
> have LDIF data which needs to be imported in the new Multimaster
> servers. That's why I used slapadd. When I did the import (slapadd)
> with the big data, it doesn't get replicated. To check the problems I
> did the import with single entry only.

It is not now, nor has it ever been, supported to do an offline add via
slapadd on a master, and then magically expect that to replicate out to a
consumer via syncrepl.  Syncrepl is an active protocol (it replicates the
changes that occur while slapd is running).  If you are going to offline
modify slapd on the master, you will have to do the same thing on the
replicas, OR reload them via slapadd, OR trigger a refresh manually on
the replicas.

How to trigger a refresh on a replica?

One question:

  My disaster recovery (and sandbox initialization) is using slapadd to
  bring up a fresh instance of my ldap environment. Technically:

    - bring up n replicated slapds with an empty db
    - stop them
    - slapadd the db dump into A
    - start A
    - start B..

  That always worked. By now, I have to say.
  I even use slapadd without -w.

  Do I understand correctly, that I should prefer the use of ldapadd?
  Does ldapadd also support operational and user attributes?

You should just slapadd A & B at the same time. It's the most efficient way to load an OpenLDAP Server.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Manager, Systems Team
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc