[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl replication on 2.4.19 (stable)
Brett @Google wrote:
> On Thu, Nov 5, 2009 at 4:20 AM, Howard Chu <hyc@symas.com
> <mailto:hyc@symas.com>> wrote:
>
>
> > Out of interest, has the syncrepl UUID / CSN format changed much
> between
> > 2.4.16 stable and 2.4.19 stable ?
>
> There have been no format changes. You should have been able to run
> 2.4.19
> directly on the original database. No idea what issue you ran into.
>
>
> The problem came back, but I think i found the root cause. We have a
> batch script which starts slapd, it has always been the same on both the
> producers and consumers. The "-w" slapadd option was being provided in
> this script, for both the consumer and the producer. This has been the
> case for quite some time (2.3.x and 2.4.16), but it only recently became
> an issue after the upgrade to 2.4.19. The sync problem would then appear
> or disappear randomly, depending of which of the provider or consumer
> was loaded first.
>
> Is it patently wrong to provide the "-w" option on the consumer, or is
> this a bug ?
Yes, it's generally wrong to use the -w option.
slapadd is intended for use with LDIF that was produced with slapcat. When you
are slapcat'ing a database that has already been in use as a sync provider,
then there should already be a valid contextCSN in the database and it will
already be present in the LDIF. Once you have this LDIF from slapcat you
should be able to load it on any other server without using -w.
The only correct usage of -w is when you have an LDIF produced by slapcat on a
database that was not being used with replication before, and so is missing
the contextCSN. But all the other operational attributes (entryUUID and
entryCSN in particular) are present and valid.
If you have an LDIF file that contains no operational attributes, it is very
likely that you ought to load it using ldapadd. If your LDIF file did not come
from a known good slapd server, then most likely it needs all of the
additional validation checks that are performed through ldapadd.
Note that slapadd was changed in 2.4.19 to warn if you're loading a replica
and entryCSN or entryUUID are missing.
> At the very least it is probably a usability "gotcha", if not a bug.
>
> If this is an issue perhaps slapadd should refuse to do "-w" on a shadow
> context, or warn and not actually perform the option ?
If the contextCSN was already present, and actually matches the max entryCSN
present in the LDIF, then the write that -w performs should be effectively a
no-op. If there were no entryCSNs in the LDIF then the value written by -w
will just depend on the current time of day when the last entry got processed
by slapadd.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/