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@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 change).
Any suggestions on where to look in the accesslog overlay to see why these modify operations are not being recorded?
Thanks,