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

Re: (ITS#3459) Selective replication producing extra blank lines that break replication



2.1 is historic, which means that even in the evidence of a problem no new
releases will occur; of course, this ITS could well host a patch, whenever
available, but no efforts are likely to be spent in fixing historic
releases.

I suggest you check whether the problem exists in current releases
(2.2.20); in case it doesn't, the solution is to upgrade.

p.


> Full_Name: Bryan Wann
> Version: 2.1.29-1
> OS: Linux Fedora Core 2 - 2.6.8-1.521
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (216.166.58.68)
>
>
> I use a 2.1 server to replicate out to 2.0 servers.  In slapd.conf under
> 'replica' I have "attr!=entryCSN,entryUUID,modifiersName,modifyTimestamp"
> configured to withhold attributes from my 2.0 servers.  The problem I'm
> seeing
> only appears when there's more than one replica configured and only when
> doing
> "add: objectClass" operations.
>
> After the "add: objectClass" data is written, there is a series of
> modifies to
> update entryCSN, modifiersName, modifyTimestamp.  When these attributes
> are
> withheld from replicas, there is still something writing a '\n' to the
> replication log in place of the withheld replicated data for each instance
> of
> replica.
>
> For example, if you have four replicas with "attr!" configured, there are
> four
> '\n' being written out to the replication log:
>
> ==========
> time: 1104447088
> dn: cn=bryan,ou=People,o=wann
> changetype: modify
> replace: entryCSN
> entryCSN: 2004123022:51:28Z#0x0002#0#0000
> -
> replace: modifiersName
> modifiersName: cn=admin,o=wann
> -
> replace: modifyTimestamp
> modifyTimestamp: 20041230225128Z
> -
>
>    [four blank lines here]
>
>
> ==========
>
> Slurpd will correctly read in this replication log, send the "add:
> objectClass"
> to it's slaves.  However, anything after the extra blank lines slurpd will
> not
> process.    For all operations afterward, slurpd debugging shows it's
> aware
> there's new data in slapd's master log and will append this to
> slurpd.replog.
> After that, the only way to get slurpd to continue replicating is to
> remove the
> extra blank lines from the replog.
>
> I /think/ the culprit is in servers/slapd/repl.c in replog1() or
> print_vals().
>
> I have looked through ITS and I haven't found anything that seems to
> specifically acknowledge this problem.  ITS #2889 sounds like it may be
> vaguely
> related, but I'm not sure.
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497