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

RE: replogcopy functionality (ITS#3030)

This is very true, unless you replicating the entire directory to a slave
(as we are).  I planned to use the replogcopy for a seperate replication
service that would replicate to non-LDAP data storage (like a mainframe).
But since that kind of replication wouldn't be tied into slurpd, it needed
its own copy of the replog that it could manage based on its own needs.

The correct way to implement a changelog would be quite different and would
require changes in slapd instead.  Perhaps I will work on that as time

-----Original Message-----
From: Howard Chu
To: digant@uta.edu; openldap-its@OpenLDAP.org
Sent: 3/24/2004 5:29 PM
Subject: RE: replogcopy functionality (ITS#3030)

slurpd and the replog works as designed. If you want a permanent log of
changes on a server, the existing replog is NOT the proper mechanism.
that the contents of the replog can be filtered by slapd.conf
directives, and
so it will not necessarily contain a complete record of changes.

The code that is used to generate the replog may be a good starting
point for
a definitive changelog. But the two concepts are not the same, and using
replog in this role is wrong, for the simple reason that the replog is
always a complete record.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of digant@uta.edu
> Sent: Wednesday, March 24, 2004 2:59 PM
> To: openldap-its@OpenLDAP.org
> Subject: RE: replogcopy functionality (ITS#3030)
> If the intent of the replogfile is simply to provide
> information to the
> replication service (slurpd) than perhaps it isn't a flaw
> that slurpd clear
> the log when it is done with the information.  But since a
> preserved track
> of the changes would be valuable, the replogcopy feature
> would address that
> need.
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> To: openldap-its@OpenLDAP.org
> Sent: 3/24/2004 4:18 PM
> Subject: Re: replogcopy functionality (ITS#3030)
> > Ando,
> >
> > That is not how the replog's work at all:
> >
> > slapd writes a replog file.
> >
> > slurpd reads that replog file, and zero's it out, and writes its own
> > copy.
> >
> > slurpd passes the changes on to the replica's.  After the changes in
> the
> >  file have been passed on, it deletes all but the last few changes
> that
> > the  replica's have received.  Thus, <all> changes are
> *not* kept over
> > time.
> OK, then I must have missed that; I would then consider this a flaw,
> because there should be a track of the changes being made to
> the server
> over time.