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

Re: delta-syncrepl missing changes

To: Francis Swasey <Frank.Swasey@uvm.edu>
Subject: Re: delta-syncrepl missing changes
From: Quanah Gibson-Mount <quanah@zimbra.com>
Date: Tue, 10 Mar 2009 09:20:43 -0700
Cc: OpenLDAP-Software@openldap.org
Content-disposition: inline
In-reply-to: <49B67DE9.1040506@uvm.edu>
References: <49831294.1040508@uvm.edu> <102CEF6B4E15BF3FC77B510E@[192.168.1.199]> <499C17DF.2060204@uvm.edu> <499C214B.5020308@uvm.edu> <9B489794211A536621AB6B44@[192.168.1.199]> <499C5995.4070002@uvm.edu> <499D5316.5010909@uvm.edu> <499DB3B9.1070702@uvm.edu> <49AD74FB.7090309@uvm.edu> <49AD89F3.4080806@symas.com> <49AE77BF.6000406@uvm.edu> <49AED568.4080709@stroeder.com> <4DD8A1231798B1A74924ADA5@[192.168.1.199]> <49AF398C.9060300@uvm.edu> <49B11753.2000605@uvm.edu> <71EC1D54A12FB4BB2E4DFEDB@[192.168.1.199]> <49B67DE9.1040506@uvm.edu>

--On Tuesday, March 10, 2009 10:49 AM -0400 Francis Swasey <Frank.Swasey@uvm.edu> wrote:

On 3/9/09 2:57 PM, Quanah Gibson-Mount wrote:

--On Friday, March 06, 2009 7:30 AM -0500 Francis Swasey
<Frank.Swasey@uvm.edu> wrote:

This hypothesis has been confirmed with the modifications that didn't
make it to the replicas yesterday morning and this morning.

Looks like the race conditions in accesslog/syncrepl that are being
worked on in the ITS's against 2.4 were present in the later 2.3 systems
as well.


I'm not sure what race conditions you're referring to here.  Using
accesslog serializes writes, therefore you can't hit the race conditions
about updating the CSN that are being worked on in current RE24.

I'll note that my 2.3.43 builds are actually a hybrid with some 2.4
code. I don't believe there's anything accesslog specific in it, but
there is some connection code reworking that is a part of it (the
lightweight dispatcher from 2.4, most notably).  I've yet to see this
with any of our deployments and some of them are quite large and
extremely busy.


To be specific, there are changes that make it into the master server,
and the auditlog overlay logs them, but the accesslog overlay does NOT
put them in the accesslog database, so they do not get sent to the
replica servers.

It seems to be some kind of race condition.  I haven't figured out a way
to reproduce the failure yet.

Oh, you have auditlog in place too? I don't believe you mentioned that before. I bet it is related to them both being enabled.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Follow-Ups:
- Re: delta-syncrepl missing changes
  - From: Francis Swasey <Frank.Swasey@uvm.edu>

References:
- Re: delta-syncrepl missing changes
  - From: Francis Swasey <Frank.Swasey@uvm.edu>
- Re: delta-syncrepl missing changes
  - From: Howard Chu <hyc@symas.com>
- Re: delta-syncrepl missing changes
  - From: Francis Swasey <Frank.Swasey@uvm.edu>
- Re: delta-syncrepl missing changes
  - From: Michael Ströder <michael@stroeder.com>
- Re: delta-syncrepl missing changes
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- Re: delta-syncrepl missing changes
  - From: Francis Swasey <Frank.Swasey@uvm.edu>
- Re: delta-syncrepl missing changes
  - From: Francis Swasey <Frank.Swasey@uvm.edu>
- Re: delta-syncrepl missing changes
  - From: Quanah Gibson-Mount <quanah@zimbra.com>
- Re: delta-syncrepl missing changes
  - From: Francis Swasey <Frank.Swasey@uvm.edu>

Prev by Date: Re: slapd syncrepl consumer having permanent high CPU load
Next by Date: Re: slapd syncrepl consumer having permanent high CPU load
Index(es):
- Chronological
- Thread