Just to close this thread… After applying the ITS#8990 patch and making the recommended configuration changes, replication seems to be behaving itself even after a weekend of heavy updates to LDAP.
Thanks for all of the advice. > On May 24, 2019, at 4:45 PM, Quanah Gibson-Mount <[email protected]> wrote: > > --On Friday, May 24, 2019 5:08 PM -0400 "John C. Pfeifer" <[email protected]> > wrote: > >>> Adding values to an attribute is exactly what ITS#8990 was dealing with, >>> so I'm not sure you think it's not a concern. The issue was with the >>> way in which the attribute was modified. >> >> Looking at >> http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8990;selectid=89 >> 90, ITS#8990 seems to be about deleting values, not adding them. Is >> there somewhere else that I should be looking for more details? > > > The issue is how an attribute value is added, particularly when Python is > being used to do the change. In any case, the underlying problem affects > multiple operations. Again, the accesslog entry for the change from *both* > masters must be compared. The issue in ITS#8990 goes something like this: > > master A receives the change > master B successfully replicates the change, but records it incorrectly in > the accesslog. > > downstream replica pulls the change from master B, and it fails. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > // John Pfeifer Division of Information Technology University of Maryland, College Park
