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.
No. Standard syncrepl always uses whole-entry updates.
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.
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.
