> --On Tuesday, January 15, 2013 6:53 PM +0000 Chris Card
> <[email protected]> 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=configreplication strangeness.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 messageslike this:
"do_syncrep2: rid=xxx (4096) Content Sync Refresh Required"
I have worked out why this is: the slapd server corresponding to rid=xxx is
tryingto search for entries in its cn=accesslog database with entryCSN <= the
contextCSN of itsmain database, but failing to find any matches, because the
cn=accesslog database wascreated 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
databaseagainst this server after the accesslog database is created, but this
does seem like a bug tome.
Chris
