Re: Copying trees from one consumer to another

[Nick Urbanik <nick.urbanik@optusnet.com.au>]

Dear Howard,

Thank you for taking the time to answer.

On 22/06/10 07:34 -0700, Howard Chu wrote:
> Nick Urbanik wrote:
> > Dear Folks,
> >
> > With slurpd, copying a tree from one slave to another was like this:
> > 1. stop slapd on both slaves.
> > 2. netcat the directory across from one slave to the other.
> > 3. stop slurpd on master
> > 4. edit slurpd.status to make the time and replication number match
> >     by copying that for the source to that for the destination slave.
> > 5. start everything back up.
> >
> > My question with syncrepl is:
> >
> > How do I copy the database for a tree from one consumer to another
> > consumer (of the same producer) so that the newly copied replica knows
> > where its replication should continue from?
> >
> > Is the state for replication of the database stored in the contextCSN
> > of the suffix entry?
> >
> > If so, does that mean that with syncrepl, the above operation is
> > reduced to the following three steps?
> >
> > 1. Stop slapd on both consumers.
> > 2. Netcat the database from one to the other.
> > 3. start both consumers.
>
> The procedures you described would only have worked in the past if 
> all of the servers had identical architecture.

Yes, the slaves are in a cluster of eight, and are all the same
architecture.

> The only supported means for copying databases is using slapcat and
> slapadd, which use LDIF and are architecture-independent.

But in the case where the consumers are all the same architecture, do
you see a problem with making binary copies of the database?

> There is no need to stop the first consumer when running slapcat.

This puzzles me; with hundreds of updates happening per minute, some
changes will be missed during the slapcat.  Will syncrepl cope and make
the new slave identical to the master?

I quote from
http://www.openldap.org/doc/admin24/maintenance.html#Directory%20Backups

  Slapcat can be run while slapd is active. However, one runs the risk
  of an inconsistent database- not from the point of slapd, but from the
  point of the applications using LDAP. For example, if a provisioning
  application performed tasks that consisted of several LDAP operations,
  and the slapcat took place concurrently with those operations, then
  there might be inconsistencies in the LDAP database from the point of
  view of that provisioning application and applications that depended
  on it. One must, therefore, be convinced something like that won't
  happen.
--
Nick Urbanik http://nicku.org 808-71011 nick.urbanik@optusnet.com.au
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24  ID: BB9D2C24
I disclaim, therefore I am.