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