> --On Tuesday, January 15, 2013 6:53 PM +0000 Chris Card
> <firstname.lastname@example.org> wrote:
> > This second problem doesn't happen consistently, but because I don't
> > understand why it happens or how to fix it consistently, I can't go ahead
> > with the production upgrade to delta-syncrepl, which is very frustrating.
> > We are currently running openldap 2.4.31, but I do plan to see if 2.4.33
> > or RE24 behaves better. However, looking at the openldap sources I
> > haven't spotted any fixes which look likely to help.
> > Any ideas?
> I take it you are replicating cn=config then? I never do that, so hard for
> me to comment on issues that may arise by doing that.
Yes, though that's not the fundamental issue, since I can work round cn=config
I've done some more investigation and I can now see what is causing the second problem.
When I change the olcSyncrepl values for the main database to use cn=accesslog
(i.e. to use delta-syncrepl rather than syncrepl), the slapd logs are flooded with messages
"do_syncrep2: rid=xxx (4096) Content Sync Refresh Required"
I have worked out why this is: the slapd server corresponding to rid=xxx is trying
to search for entries in its cn=accesslog database with entryCSN <= the contextCSN of its
main database, but failing to find any matches, because the cn=accesslog database was
created after the last change to the main database that happened through this server.
I think I can work round this by making sure an LDAP modify is done to the main database
against this server after the accesslog database is created, but this does seem like a bug to