[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slow replication
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