Re: slow replication

[Meike Stone <meike.stone@googlemail.com>]

>
> syncrepl really isn't intended for initial "full" loads, although it will
> work eventually (as you've seen). The preferred method for standing up an
> offline server is slapadd -q. syncrepl can then handle deltas since the LDIF
> was generated; this should complete fairly rapidly.
>

Ok, sound logical, but if I use slapcat on a running slapd with big
db, is it guaranteed,
that the resulting ldif is consistent and will work after slapadd?

Second is, I used a 3h old ldif from slapcat on the consumer and the
replication needed about 6h for the resync (same ContextCSN).
On the provider (master) I've set loglevel 256. So I used the script
ldap-stats.pl (http://prefetch.net/code/ldap-stats.pl.html), to
determine how many changes are made in this hour (about 5000/h). The
server hardware itself is idling the whole time (cpu/disk/nework).
On the consumer the CPU is running on nearly 100%.

Is it possible, the determine in which state (present phase, delete
phase,) the consumer is staying (e.g. monitoring db).

Is it possible to simulate the present phase with ldapsearch, to look
if the provider needs so long and if, what part (entries updated or
unchanged entry ) needs so long?

>
>> I'm of the opinion that it was significantly faster with a smaller
>> database.
>
>
> Rule of thumb, the less data to process, the less time it takes...
>

But presumably non-liniar ...


Thanks Meike