On 2/18/09 9:14 AM, Francis Swasey wrote:
On 1/30/09 1:09 PM, Quanah Gibson-Mount wrote:
> --On Friday, January 30, 2009 9:45 AM -0500 Francis Swasey
> <Frank.Swasey(a)uvm.edu> wrote:
>> I am running OpenLDAP 2.3.39 (locally built) on Red Hat Enterprise Linux
>> 4 servers with several replicas. We use delta-syncrepl to keep the
>> replicas in sync with the master server.
> Yes, this was a known issue, and both the replicas and the master must
> all be on 2.3.43, and all the replicas reloaded from a fresh dump of
> the master. Once you've done that, it should take care of the
> problems you are seeing.
I upgraded everything to 2.3.43 on January 31 and verified at the time
that everything was in sync. However, it's been a week or more since I
last audited the sync'ness of the replicas and the master. This
morning, I've discovered that the replica's are again out of date with
the master copy and there are of course no failures in the
syncrepl_message_to_op's logged on any of the replicas that would
indicate why these 36 modification's were not replicated.
So, what ITS was this supposed to be fixed by?
Is there anything that should be logged that would help identify the
failure (I'm currently using loglevel of "stats sync" on the master and
all the replicas) ?
Some further digging into this and I see that the changes this morning
to at least one of these entries are not present in the accesslog
database. No wonder the change didn't make it to the replica's, it
didn't even make it into the accesslog on the master (although auditlog
sees the change and the dc=uvm,dc=edu database on the master has the
Any suggestions on where to look in the accesslog overlay to see why
these modify operations are not being recorded?
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)