RE: replogcopy functionality (ITS#3030)

[hyc@highlandsun.com]

slurpd and the replog works as designed. If you want a permanent log of the
changes on a server, the existing replog is NOT the proper mechanism. Note
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 the
replog in this role is wrong, for the simple reason that the replog is not
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.
>
>
>