Re: syncRepl fails to replicate new trees (ITS#2948)

[jongchoi@OpenLDAP.org]

Quanah,

Sorry for some delay on catching up with you. I'm out of office now.
I'm trying to combine my answers to ITS#2948 and ITS#2987, because they seem to be related
to each other.
Also, my answer is based on my rough guess on the setup and procedures you took on your
site, so it may be inaccurate.
Please correct me if I am wrong with my guess about your setup / procedure.

Let's first look at thr procedure you took reported in ITS#2987.

> slapadd will no longer create an ldapsync entry for me in the provider DB.
>
> Steps I took:
>
> 1) Took 2.1 DB export, and remove all instances of entryUUID, entryCSN.
>
> 2) 2.2.6 slapadd of DB
>
> 3) 2.2.6 slapcat of DB
>
> 4) 2.2.6 slapadd -p -w -l DB
>
> 5) 2.2.6 slapcat -l DB
>
> grep -i ldapsync DB
>
> nothing returned.
>
> --Quanah

Here again, one procedural question ....
Did you load the provider and the consumer DB from the same ldif file which is entryUUID
and entryCSN stripped ? Or, did you load the provider from the stripped ldif file, slapcat
the provider db, and slapadding the consumer from the provider-slapcatted ldif file ? You
should not take the first path, since the syncrepl engine considers two entries the same
only when entryUUIDs are the same.
>
> --On Friday, February 27, 2004 4:09 PM -0500 Jong <jongchoi@OpenLDAP.org>
> wrote:
>
> Hi Jong,
>
> I've tried yet again, with no more luck:
>
> Master after load:
>
> dn: cn=ldapsync,dc=stanford,dc=edu
> contextCSN: 20040304011528Z#0000b4#00#000000
>
> Master after adding operational tree:
>
> dn: cn=ldapsync,dc=stanford,dc=edu
> contextCSN: 20040304021854Z#000002#00#000000
>
>
> Replica after load:
> dn: cn=syncrepl0,dc=stanford,dc=edu
> syncreplCookie: 20040304011528Z#0000b4#00#000000
>
> I note that I see the following error in the replica's log file after
> output:
>
> Mar  3 04:13:15 ldap-dev2.Stanford.EDU slapd[2482]: [ID 166296
> local4.debug] null_callback : error c
> ode 0x42
> Mar  3 04:13:15 ldap-dev2.Stanford.EDU last message repeated 3 times
>
> If I do an ldapmodify to the master, that change is again not propogated to
> the replica.  At this point, I'd say that syncRepl is completely
> non-functional in the 2.2.6 release.
>
> --Quanah

The strange behaviors you observed can be explained if it is the case that you took the
first path described above. Also, it is not appropriate to say that syncrepl is
unoperational in 2.2.6 release although we cannot say that it is operational in all setups
/configurations.

- Jong-Hyuk