Brandon Hume wrote:
I don't know whether 2.3.43 is new enough to NOT be told to go to hell,
Nobody would ever tell you that. But 2.3.43 is over a year old and 2.4 has been the stable release for quite a long time. Insisting on using it is the same as you telling us to go to hell with our bug fixes.
but it's the latest of the 2.3.x series and I can't get migrated to 2.4 until I get slurpd gone... and oddly enough, I think turning off slurpd caused some of my problems.
This morning our two slaves and master server began experiencing bad sync lag... the slaves were close to two or more hours behind the master. I discovered that a large automated job had touched over thirty thousand entries and altered the values of a lot of attributes (it was a course enrollment update, as it happens).
I *suspect* that the huge number of updates overflowed the syncprov session log and the slaves moved from small updates to whole-entry updates. My syncprov session log was set to 500... which I think was hideously undersized.
Am I correct in my assumption?
No. Standard syncrepl always uses whole-entry updates.
Stemming from that, I've noticed that trying to use LDAP to alter anything in the cn=config tree - whether it happens to be to change the session log size, or to add a new index - causes slapd to freeze. Not a true hang, as it continues to accept connections, but all operations are deferred and pending, even though slapd's CPU usage remains low. I can kill and restart slapd and I'm okay. Also, altering cn=config by editing the on-disk ldif files while slapd is dead causes no problem.
That's a side-effect of cn=config, which requires no other threads to be running before it makes a change. The scheduling mechanism has been fixed in 2.4 so this freeze no longer occurs.
And a third thing: does ~3h to add 250k entries to a new database, using 'slapcat -q' sound ridiculously long?
slapcat should be able to read the contents of a database at a rate of several thousand entries per second. But slapcat won't add any number of entries to a database, no matter how much time you give it.