[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ContextCSN generation

To: Sven Jourgensen <svenj@uic.edu>
Subject: Re: ContextCSN generation
From: Yuri Bank <yuribank@gmail.com>
Date: Sun, 21 Oct 2012 23:32:10 -0700
Cc: openldap-technical@openldap.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ae0o1TrE5IJMJ0K0Np4/RiTBraCGvZSPC4wIZf7ov4k=; b=rqKWR4tUJASTQ/NwQbRm7vyaYpo3Cnk5XBFiHtrJDsz2Q2UFddV38lxVN+5+UazEYl GLy9faVWux21fW3L10wQkgpM+xMGMNnjLAIp9AMjKAONf504I1htQuRo2563KTQs5fp7 8lnn+fF/MZaRchdqwJiK7n6XmMy9veusV6DQ1DbNtLeqKTeXJKZnEB07eUEqdnuubaCX kg+AtTd6IqmbWL6PReElQ3WKEjlu+isxE/0Cnb8EJJjNyYY3jT2A3Iz7cT+3sXDKwE8M 24lhrRJs2NAyhyXZ+33bUdZYaYRHkNrYGN/P2lnfhT8SdU131jQH3L8xofXELWd9e9Ez 8WRQ==
In-reply-to: <Pine.A41.4.58.1210101349060.77882@tigger.cc.uic.edu>
References: <Pine.A41.4.58.1210101107090.103906@tigger.cc.uic.edu> <B0A31F81E4DEBE337060794B@192.168.1.43> <Pine.A41.4.58.1210101349060.77882@tigger.cc.uic.edu>

I had the exact same problem, although my issues were tied closely to
the usage of the memberOf overlay, along with delta-sync replication.
The current Ubuntu LTS ( and Debian Wheezy) have OpenLDAP 2.4.28 which
helped quite a bit (also not using delta-sync replication anymore).

-Yuri

On Wed, Oct 10, 2012 at 11:52 AM, Sven Jourgensen <svenj@uic.edu> wrote:
> The version is 2.4.23, the config is the same across all the slaves,
> including the ones that stay in sync under load, the hardware itself is
> more than capable, I'm curious however to your clock comment, would an
> unstable clock on the slave cause the contextCSN token to be out of whack?
>
> Hence me asking rather how the contextCSN is generated and passed from
> master to slave, rather than, here's all my configs fix it for me.
>
> SJ
>
> On Wed, 10 Oct 2012, Quanah Gibson-Mount wrote:
>
>> --On Wednesday, October 10, 2012 11:07 AM -0500 Sven Jourgensen
>> <svenj@uic.edu> wrote:
>>
>> > I have an odd issue, where I have some new slaves that I added to my pool,
>> > they ran fine sync'ing with the master, etc. for weeks, until I added them
>> > into use (we're using an F5 frontend) whereupon they started getting a
>> > contextCSN which was larger than that of the master.
>> >
>> > How is the contextCSN generated, I thought the slave could never get ahead
>> > of the master, but it's happening consistently, it's not a transient
>> > thing, the slave gets a larger contextCSN and keeps it, until the master
>> > is updated again.
>> >
>> > master:     contextCSN: 20121010154339.775633Z#000000#000#000000
>> > slave1:     contextCSN: 20121010154442.858054Z#000000#000#000000
>> > slave2:     contextCSN: 20121010154351.807575Z#000000#000#000000
>> >
>> > As soon as I remove them from use, and update the master, they come back
>> > into sync.
>>
>> OpenLDAP version?  Configs for master and replicas? Have you verified that
>> the clocks on all 3 servers are in sync?
>>
>> --Quanah
>>
>>
>> --
>>
>> Quanah Gibson-Mount
>> Sr. Member of Technical Staff
>> Zimbra, Inc
>> A Division of VMware, Inc.
>> --------------------
>> Zimbra ::  the leader in open source messaging and collaboration
>>
>

References:
- ContextCSN generation
  - From: Sven Jourgensen <svenj@uic.edu>
- Re: ContextCSN generation
  - From: Sven Jourgensen <svenj@uic.edu>

Prev by Date: Re: LDAP Architecture for CardDAV/OpenLDAP interface
Next by Date: Search response attribute/alias names
Index(es):
- Chronological
- Thread