Re: (ITS#8396) syncprov hourly fails to answer syncrepl

[quanah@zimbra.com]

--On Thursday, April 07, 2016 4:22 AM +0000 quanah@zimbra.com wrote:

> So the change is still correctly replicated to the replicating MMR node.

I see the same behavior with the example configuration that was provided as 
well.  While the CSN bit may not be logged, the change is replicated as it 
should be.

Provider:

Apr  6 22:59:28 zre-ldap002 slapd[22212]: slap_queue_csn: queueing 
0x4ab3600 20160407035928.515652Z#000000#000#000000
Apr  6 22:59:28 zre-ldap002 slapd[22212]: slap_graduate_commit_csn: 
removing 0x4ab3600 20160407035928.515652Z#000000#000#000000
Apr  6 22:59:28 zre-ldap002 slapd[22212]: syncprov_sendresp: cookie=rid=100
Apr  6 22:59:28 zre-ldap002 slapd[22212]: conn=1003 op=1 RESULT tag=103 
err=0 etime=0.084274 text=


Replica:

Apr  6 22:59:28 zre-ldap003 slapd[7947]: do_syncrep2: rid=100 cookie=rid=100
Apr  6 22:59:28 zre-ldap003 slapd[7947]: slap_queue_csn: queueing 0x37403c0 
20160407035928.515652Z#000000#000#000000
Apr  6 22:59:28 zre-ldap003 slapd[7947]: slap_graduate_commit_csn: removing 
0x37403c0 20160407035928.515652Z#000000#000#000000
Apr  6 22:59:28 zre-ldap003 slapd[7947]: syncrepl_message_to_op: rid=100 
be_modify uid=fcs,ou=People,dc=uvm,dc=edu (0)


So while the lack of the ,csn bit is annoying... I see no actual data loss, 
etc.

--Quanah



--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc