yes

overlay ppolicy

and

overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100

So it looks like on node 3 I have both syncprov and syncrepl defined?

"overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100

syncrepl rid=003 ..... "

But actully when I try to write to node 3 directly, I have a error like this, "ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral "

Thanks

Frank

On Tue, May 24, 2016 at 7:31 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:

Do you have any overlays on the replicas?

--Quanah

--On Tuesday, May 24, 2016 4:55 PM -0400 Frank Luo frank.luoy@gmail.com wrote:

...

but we always have two masters - and you can tell that this is pretty current time tag.

contextCSN: 20160521215740.310825Z#000000#000#000000

Does this mean the slave gets updated from some other source in additional to the two masters.

I am attache the replication portion of the slaver sever 3, server2.u.com is one of the two masters

syncrepl rid=003 provider=ldap://server2.u.com bindmethod=simple binddn="cn=Manager,dc=u,dc=com" credentials=password searchbase="dc=u,dc=com" schemachecking=on type=refreshAndPersist retry="60 +"

Thanks

Frank

On Tue, May 24, 2016 at 12:54 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:

...

Sure -- 000 is from when things were single master.

--Quanah

--On Tuesday, May 24, 2016 12:37 PM -0400 Frank Luo frank.luoy@gmail.com wrote:

...

Thanks. The two servers were off by 15 seconds

I also checked contextCSN and see there were more than 1 values - any idea there are multiple?

To help you understand we have a multiple(2) masters and three slaves.

on two masters (node1 and node 2), each has two contextCSN like this, I can understand since they are in mirror mode, it get updates from each other

node 1: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152340.159717Z#000000#002#000000

node 2: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152340.159717Z#000000#002#000000

on three slavers (nodes3,4 and5), each has 3 contextCSN. Where does the third contextCSN come from - you can see the third one is out of sync with each other.

node 3: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160521215740.310825Z#000000#000#000000 contextCSN: 20160524152340.159717Z#000000#002#000000

node 4: contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152558.806951Z#000000#000#000000 contextCSN: 20160524152340.159717Z#000000#002#000000

node 5: contextCSN: 20150723095205.352520Z#000000#000#000000 contextCSN: 20160524152519.525094Z#000000#001#000000 contextCSN: 20160524152340.159717Z#000000#002#000000

THanks

Frank

On Mon, May 23, 2016 at 5:11 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:

...

--On Monday, May 23, 2016 5:56 PM -0400 Frank Luo frank.luoy@gmail.com wrote:

...

All,

I am having a out-of sync situation now with some entries' entryCSN is larger (later) in consumer node than in provider node. So the consumer never gets updated since it thinks it has the latest value.

Check the clocks on each server. It is required that your clocks be tightly sync'd.

--Quanah

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc