On Mon, Dec 12, 2022 at 04:58:44PM +0100, Michael Ströder wrote: > On 12/12/22 16:47, [email protected] wrote: >> For one particular use case we replicate a subset of the application >> database, but our replication check cannot work for this use case. > Partial replication is somewhat tricky because the highest entryCSN value > seen in a replicated entry might not the same like the highest entryCSN > value in the full data set (the latter stored as contextCSN at the > provider). > > So from my understanding just comparing contextCSN values will not work.
Comparing entryCSN values will not work because of what you note, but if using OpenLDAP's own syncrepl (olcSyncrepl), contextCSNs should work just fine as they record whatever has been passed in the cookies. It might be necessary to retrieve if from the right place (manageDSAit on the suffix entry or reading the subentry if it was necessary to store contextCSN there). As usual I will note that you don't want to use contextCSNs for anything apart from being able to tell whether the contextCSN sets are up to date or not. Especially avoid guessing "replication delay" from its differences, doing so will yield meaningless values more often than you think. If you want to measure replication delay, use a time-series DB or syncmonitor[0]. > Since release 2.5 there's more replication info in back-monitor. Didn't have > the time to adapt my own monitoring checks to this though. [0]. https://git.openldap.org/openldap/syncmonitor Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
