Re: entryCSN is larger (later) in consumer node than in provider node

[Quanah Gibson-Mount <quanah@zimbra.com>]

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