On Thu, Oct 13, 2022 at 07:27:24AM -0500, Shawn McKinney wrote: > On Oct 12, 2022, at 9:25 AM, Frédéric Goudal > <[email protected]> wrote: >> The behaviour that seems to occurs is that the logging sometimes stop >> (nothing more to do it seems) and when it stops the servers are in >> sync. So it seems the sync operations are very slow. Of course I do >> not log on normal operation. > > Where I’d start is to quantify how far out of sync they’re getting. A > good tool for that is the slapd watcher. It calculates based on > contextCSN’s and also provides stats from the monitor database. > > ldap://m02 > > Entries Bind Unbind Search Compare Modify > ModDN Add Delete Abandon Extended > Num 578764 502 1 44492 1 1 > 0 1805517 1515081 0 102 > Num/s 0.00 0.00 0.00 0.19 0.00 0.00 > 0.00 0.00 0.00 0.00 0.00 > contextCSN: 20221011141123.463727Z#000000#001#000000 actv@2022-10-10 > 13:08:15, idle@2022-10-11 19:16:45 > contextCSN: 20221011141123.851236Z#000000#002#000000 actv@2022-10-10 > 13:08:15, ahead 16:17:51, max delta 16:17:51
I would note that slapd-watcher's 'max delta' is *not* the same as replication delay, treating is as such would be committing the same mistake as most replication monitoring tools out there are doing. Watcher's output is for manual realtime monitoring and needs to be interpreted with caution. To measure replication delays one needs to take out a clock and measure how long it actually took, never calculate the difference of CSNs. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
