On Fri, 26 Apr 2013, Meike Stone wrote:
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?
It should be as consistent as any other reading client -- it's explicitly intended to work with 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%.
You might want to verify your syncprov and syncrepl syncdata= settings are appropriate for your workload.
Is it possible, the determine in which state (present phase, delete phase,) the consumer is staying (e.g. monitoring db).
debug level sync should give you a hint at to where the consumer is.
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?
You should be able to form the controls with ldapsearch, but I don't believe ldapsearch can create a persistent client. I'm pretty sure that there are freestanding clients out there if you want to play around with refreshAndPersist.
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