|
> --On Tuesday, January 15, 2013 6:53 PM +0000 Chris Card
> <ctcard@hotmail.com> 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 replication 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 messages like 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 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 me. Chris |