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

--On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey@uvm.edu wrote:

Hi Frank,

Actually, I see this affects all forms of replication. On my ldap servers it is much more frequent than hourly:

Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003

Interestingly, for MMR, this does not result in any data loss, as the changes are replicated w/o problem:

MMR node taking writes:

Apr 6 21:56:47 ldap01 slapd[34514]: slap_queue_csn: queueing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: slap_graduate_commit_csn: removing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: conn=2909 op=286509 RESULT tag=103 err=0 etime=0.000935 text= Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003

MMR node receiving writes:

Apr 6 21:56:47 ldap02 slapd[61570]: do_syncrep2: rid=102 cookie=rid=102,sid=003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x80ee240 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: syncprov_matchops: skipping original sid 003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x80ee240 20160407025647.107497Z#000000#003#000000

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

--Quanah

--

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