On 3/10/09 1:19 PM, Quanah Gibson-Mount wrote:
--On Tuesday, March 10, 2009 1:08 PM -0400 Francis Swasey
<Frank.Swasey(a)uvm.edu> wrote:
> On 3/10/09 12:20 PM, Quanah Gibson-Mount wrote:
>> --On Tuesday, March 10, 2009 10:49 AM -0400 Francis Swasey
>
>>> 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.
>
> It is the first time I've mentioned it in this thread, but I've mentioned
> it in previous threads.
>
> So -- why would having auditlog and accesslog (and syncprov) all used
> with a database cause accesslog to miss some of the changes?
I don't know. :/ But I do know I've never seen it in very
write-intensive environments, and that is a major difference.
Do writes to go auditlog before accesslog in your configuration? Maybe
there's a bug in auditlog under a high-write load where the changes
don't get cleaned up properly. If auditlog is being written first, try
reversing the order, so that accesslog gets the changes first (I assume
that's possible).
If I remember correctly that the overlays get control in the reverse
order of their listing (ie, the last one listed is the first one
executed), then yes, the auditlog is run first, then accesslog, then
syncprov.
I'll do some experimenting with the order and see if I can list auditlog
first so it runs last.
--
Frank Swasey |
http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)