Howard Chu wrote:
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.Moving to 2.4 is very, very much a priority for me. But I was under the impression that slurpd is actually physically gone from 2.4, and I've got other systems dependent on it. I'm working on changing/ridding myself of them, but I have to be careful (especially with internal pressure from above to switch to AD). Alas, disasters don't care for schedules.
I'm only looking to dig out of the hole I'm in right at this very moment so that I can concentrate on moving everything to 2.4.
I thought I was using partial updates, but was wrong. Your reply has given be enough keywords to find the proper configuration in the docs. I can fix that today, hopefully.No. Standard syncrepl always uses whole-entry updates.
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.Okay... and when I was running slurpd for replication, I was slipping in between updates to make successful changes. Now that I've got the secondary servers running refreshAndPersist there's always a thread running. It seems to make sense.
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.
Oops. s/slapcat/slapadd/ Sorry the mistake wasn't more obvious.