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

[quanah@stanford.edu]

--On Thursday, March 04, 2004 1:23 PM -0500 Jong <jongchoi@OpenLDAP.org> 
wrote:

Hi Jong,

I understand about being on vacation -- It is a wonderful thing to do.

> 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.

Hi Jong,

Here is the path that I took:

1) strip DB of entryUUID & entryCSN

2) Load DB on provider (with -p -w -l)

3) slapcat -m -l DB

4) Copy provider generated DB to replica

5) slapadd -r -l DB

So all entryUUID, entryCSN pieces should match.

I note:

diff -u db_syncrepl_m db_syncrepl_r

returns:

ldap-dev2:/# diff -u db_syncrepl_m db_syncrepl_r
--- db_syncrepl_m       2004-03-04 10:46:09.000000000 -0800
+++ db_syncrepl_r       2004-03-04 10:44:39.000000000 -0800
@@ -15676214,12 +15676214,12 @@
 entryUUID: 2b3126fc-01c5-1028-8bd9-8075041b1e70
 entryCSN: 20040304011528Z#0000b4#00#000000

-dn: cn=ldapsync,dc=stanford,dc=edu
+dn: cn=syncrepl0,dc=stanford,dc=edu
 objectClass: top
 objectClass: subentry
-objectClass: syncProviderSubentry
+objectClass: syncConsumerSubentry
 structuralObjectClass: subentry
-cn: ldapsync
-contextCSN: 20040304011528Z#0000b4#00#000000
+cn: syncrepl0
+syncreplCookie: 20040304011528Z#0000b4#00#000000
 subtreeSpecification: {}


Where db_syncrepl_m is a slapcat -m -l on the provider, and db_syncrepl_r 
is a slapcat -k -l on the replica.  So in my 481MB database dump, the only 
things that differ are the syncrepl0/ldapsync entries.


> 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.

It has gone from a point of where it partially worked in 2.2.5 to a point 
where I get no updates propagating in 2.2.6.  I don't see anything 
spectacular about my configuration, I know that the syncrepl connection is 
being made between the provider and replica, and that the replica has full 
read on the master.  That tends to indicate to me that it isn't functional.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html