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 <[email protected]> wrote:
> Sure -- 000 is from when things were single master.
>
> --Quanah
>
> --On Tuesday, May 24, 2016 12:37 PM -0400 Frank Luo <[email protected]>
> 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 <[email protected]>
>> wrote:
>>>
>>> --On Monday, May 23, 2016 5:56 PM -0400 Frank Luo <[email protected]>
>>> 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
