Re: (ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing

[quanah@zimbra.com]

--On Thursday, July 02, 2009 3:40 PM -0700 Quanah Gibson-Mount 
<quanah@zimbra.com> wrote:


> So, it appears to me that even though it must have at some point accepted
> the first change, the entry on the server is not truly updated to reflect
> that for some reason?  That, or it "skipped" that change for reasons
> unknown to me.

Adding to the mystery, is what the server believes the entry looks like, 
even across restarts:

dn: uid=acyen,cn=accounts,dc=stanford,dc=edu
suSeasSunetID: acyen
suDialinStatus: active
suCreateAgent: AccountSlog
suService: dialin
suService: afs
suService: leland
suService: email
suService: pts
suService: seas
suService: kerberos
suEmailAdmin: acyen
suSeasUriRouteTo: /~acyen
suName: XXXXXXX
uid: acyen
suNameLF: XXXXXXXX
suSeasStatus: active
suKerberosStatus: active
suEntryStatus: active
suAccountStatus: active
krb5PrincipalName: XXXXXXXX
suSeasLocal: XXXXXXXXX
suEmailAccountType: personal
suAfsStatus: active
suEmailStatus: active
suMailDrop: XXXXXXXXX
suCreateAPI: JNDI
suKrb4Name: XXXXXXXXXX
suPtsStatus: active
suLelandStatus: active
gecos: XXXXXX
cn: XXXXXXX
suAfsHomeDirectory: /afs/ir/users/a/c/acyen
suPtsUid: 28906
loginShell: /bin/tcsh
uidNumber: 28906
gidNumber: 37
homeDirectory: /afs/ir/users/a/c/acyen
objectClass: posixAccount
objectClass: suPtsService
objectClass: suAccount
objectClass: suOperational
objectClass: suAfsService
objectClass: suEmailService
objectClass: suLelandService
objectClass: suDialinService
objectClass: suKerberosService
objectClass: suSeasService
suIdentifies: 
suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,d
 c=edu
seeAlso: 
suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu
owner: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu
description: XXXXXXXXXX
suEmailQuota: 1000
suDescription: XXXXXXXXXX
structuralObjectClass: suAccount
entryUUID: bd300052-dbd5-102c-8575-cd5814f999c3
creatorsName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu
createTimestamp: 20080701162309Z
modifiersName: 
cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu
modifyTimestamp: 20090210171734Z
entryCSN: 20090702065034.772554Z#000000#000#000000
entryDN: uid=acyen,cn=accounts,dc=stanford,dc=edu
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

The first change, which we'd think had gone across given it is stuck on the 
second change, never appears to have been applied, but nothing was ever 
logged about this.  The attributes and objectClass that were supposed to be 
deleted are still present.  The value changes that were supposed to occur 
haven't.

Now, the entryCSN is:
20090702065034.772554Z#000000#000#000000

vs the change time which is:

20090702070150.000014Z

so clearly, the entry has never been updated with the change.  Yet it 
*should* have been.  How did we end up skipping a change from the accesslog 
db????

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration