On Tue, Aug 25, 2009 at 6:11 PM, Francis Swasey <Frank.Swasey@uvm.edu> wrote:

On 8/25/09 11:45 AM, Aaron Richton wrote:

On Tue, 25 Aug 2009, Lepoutre Lionel wrote:

My problem is that some data are not synchronised on one of my server and I
have some "log.xxxx" files in my var/openldap-data/ directory.

When I had an issue with my replicas getting out of sync I developed a process to slapcat each of the replica's generate what was different from the master and cause the master to make the changes again (ie, reverse the master and then revert to what the master knew was correct) which caused the information to get pushed to the replica's again. In my case, the problem turned out to be one of my replica's had too little memory and was triggering a bug in v2.3 which caused the changes for delta-syncrepl to not get logged in the accessdb on the provider.

The gist of the process I developed was to ssh to each replica, slapcat the existing database, sftp that back to the master, slapcat the master's database, use an ldif diff tool to generate the changes as if the replica was the master, apply those changes to the master, then do the ldif diff in the other direction and apply those changes to the master. It was an attrocious hack, but it allowed me to re-sync the replica's without having to wait for the load balancers to take them out of the service pool and rebuild them by hand on a regular basis.

However, having log.xxxx files is not a sign that anything is wrong. Even with auto-removal of the log.xxxx files, you will always have at least one present and if you have a massive change happen, you may get a few before the checkpoint happens and makes them superfluous.

How have you determined that your servers are not in sync?

--
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)