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

[jongchoi@OpenLDAP.org]

Given the format difference of the contextCSN,
it seems that the initial ldif file was slapcatted three+ months ago...
This format change applies to the entryCSN as well.
If this is the case, suggest to regenerate the ldif.
- Jong

----- Original Message ----- 
From: "Quanah Gibson-Mount" <quanah@stanford.edu>
To: "Jong" <jongchoi@OpenLDAP.org>
Cc: <openldap-its@OpenLDAP.org>
Sent: Wednesday, February 25, 2004 12:48 PM
Subject: Re: syncRepl fails to replicate new trees (ITS#2948)


> 
> 
> --On Friday, February 13, 2004 5:43 PM -0500 Jong <jongchoi@OpenLDAP.org> 
> wrote:
> 
> Jong,
> 
> This information might help some more --
> 
> After the initial load, the contextCSN on the master is:
> 
> dn: cn=ldapsync,dc=stanford,dc=edu
> contextCSN: 2004012809:52:53Z#0x0001#0#0000
> 
> After I add the operational tree, the contextCSN on the master is:
> dn: cn=ldapsync,dc=stanford,dc=edu
> contextCSN: 20040225010006Z#000003#00#000000
> 
> After the initial load on the replica, the syncreplcookie is:
> 
> # syncrepl0, stanford.edu
> dn: cn=syncrepl0,dc=stanford,dc=edu
> syncreplCookie: 2004012809:52:53Z#0x0001#0#0000
> 
> 
> 
> It looks to me that the change of adding the operational tree significantly 
> modifies the contextCSN, which is triggering the full data dump, even 
> though the amount of change to the DB is minimal.  Thoughts?
> 
> --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
> 
>