>>> Quanah Gibson-Mount <qua...@symas.com> schrieb am 20.01.2022 um 18:02 in Nachricht <65ABF4684C2D1F77600EF736@[192.168.1.27]>:
> > ‑‑On Wednesday, January 19, 2022 4:26 PM +0200 skeletor > <skele...@lissyara.su> wrote: > >> Hi. >> I use delta‑sync replication on version 2.4. Sometimes, some records >> don't send to slave. Insofar as this is delta‑sync after a new update >> slave receive only last update. Therefore slave and master are not >> consistent. Is it possible run force resync from accesslog to consistent >> check if all records are present on slave? >> May be this is a bug on version 2.4 and it already has been fixed in >> newer version? >> >> master 2.4.57 >> slave 2.4.55 > > I'm not quite sure what you mean by sometimes some records don't send to > the slave. That would most generally indicate a configuration issue. You > would want to see if the record exists in the accesslog DB of the provider > corresponding to the time it was added via an ldap operation (obviously, > any entries added offline via mechanisms like slapadd would never be > replicated). I would also confirm that you do not see REFRESHes occurring > on the consumer vs the provider. I would also confirm that you haven't run > the accesslog database out of space preventing it from recording operations > (the MDB maxsize for the accesslog db). > > The only reliable way to get them in sync would be to slapcat the provider > and import it on the consumer. However, given the description of the > problem from your end, I'm not convinced they wouldn't just de‑sync again. Independent of this problem I wonder whether it is possible (proper access rights assumed) to compare the contents of all mirroring servers via LDAP efficiently. It seems the seemingly random order of entries and attributes is the major obstacle when searching just "for everything". Also an operation like "resync fully from ServerID X" would seem to be a nice idea. Regards, Ulrich
