Those files plus various header files don't seem to correspond to what
is being returned, but as I would expect, to various internal
representations of the contextCSN.
contextCSN: 20080304184021.024760Z#000000#001#000000
Seems to be a date and timestamp, YYYYmmDDhhMMss.partOfSecond, followed
by ???, then the rid, then ???.
>From the code and struct definitions I would have expected the to see a
sid and some state indicator too.
I went looking in the schema files to see if contextCSN was mentioned
with no success.
Obviously I don't know my way around the source code for OpenLDAP, but
I'm willing to keep looking if you would give me another hint. I guess
I would start trying to find where the contextCSN gets returned in the
answer to a query, but this sounds like a difficult task going through
lots of layers of the code.
Again any help would be appreciated.
Thanks.
Roy
-----Original Message-----
From: Gavin Henry [mailto:ghenry@suretecsystems.com]
Sent: Tuesday, March 04, 2008 12:30 PM
To: Marantz, Roy
Cc: openldap-software@openldap.org
Subject: RE: Testing the state of replicates
<quote who="Marantz, Roy">
> I saw the admin24 section, but thought that the contextCSN was meant
to
> be opaque.
>
> I've looked at rfc4533, but reading sections 2.1.2 through 2.3 doesn't
> give me enough information to parse the contextCSN value into
something
> I can understand. Do you know where I could get (or write) some code
to
> decode the result?
Dig the main source. servers/slapd/syncrepl.c and
servers/slapd/overlays/syncprov.c
> Thanks for your help.
> Roy
>
> -----Original Message-----
> From: Gavin Henry [mailto:ghenry@suretecsystems.com]
> Sent: Tuesday, March 04, 2008 10:49 AM
> To: Marantz, Roy
> Cc: openldap-software@openldap.org
> Subject: Re: Testing the state of replicates
>
>> Is there something I can query, like contextCSN, to indicate the last
>> time syncrepl successfully finished resyncing the particular
database?
>>
>> Any other way to do this or am I just trying to do something that is
>> impossible?
>
>
> See:
>
>
http://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Details
>
> "The consumer also stores its replica state, which is the provider's
> contextCSN received as a synchronization cookie, in the contextCSN
> attribute of the suffix entry. The replica state maintained by a
> consumer
> server is used as the synchronization state indicator when it performs
> subsequent incremental synchronization with the provider server. It is
> also used as a provider-side synchronization state indicator when it
> functions as a secondary provider server in a cascading replication
> configuration. Since the consumer and provider state information are
> maintained in the same location within their respective databases, any
> consumer can be promoted to a provider (and vice versa) without any
> special actions."
>
> And more detail at:
>
> http://www.rfc-editor.org/rfc/rfc4533.txt
>
> For example:
>
> [ghenry@suretec-master admin]$ ldapsearch -x -H ldap://127.0.0.1 -s
> 'base'
> contextCSN
> # extended LDIF
> #
> # LDAPv3
> # base <dc=suretecsystems, dc=com> (default) with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # suretecsystems.com
> dn: dc=suretecsystems,dc=com
> contextCSN: 20080228163422.801358Z#000000#000#000000
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> [ghenry@suretec-slave admin]$ ldapsearch -x -H ldap://127.0.0.1 -s
> 'base'
> contextCSN
> # extended LDIF
> #
> # LDAPv3
> # base <dc=suretecsystems, dc=com> (default) with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # suretecsystems.com
> dn: dc=suretecsystems,dc=com
> contextCSN: 20080228163422.801358Z#000000#000#000000
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
>
>