[Date Prev][Date Next] [Chronological] [Thread] [Top]

syncrepl openldap-2.3.17



I did a slapadd of a database to the master, with this in the config:

overlay syncprov
syncprov-checkpoint 10 10
syncprov-sessionlog 100

A slapcat of that database returned identical info to the original ldif file.

slapadd'ing that original ldif to the slave, with

syncrepl	rid=1 provider=ldap://utility5.wpi.edu type=refreshAndPersist searchbase=dc=WPI,dc=EDU scope=sub retry="60 5 300 +" attrs="*" filter="(objectclass=*)" starttls=critical bindmethod=simple binddn=cn=Manager,ou=Access,dc=WPI,dc=EDU credentials=xxxxxx
updateref	ldap://utility5.wpi.edu

in the config, resulted in a pretty busy slave server after both slapd's were
started.

Terminating them after a few minutes, and slapcat'ing the master, there is a
contextCSN in the master; no other changes from the original ldif.  The slave
appears to have some number of creatorsName, createTimestamp, modifiersName,
modifyTimestamp, etc., removed.  I guess it was in the process of removing all
those.  About the first 1% of the slapcat'd ldif had these changes; I assume it
was sweeping through the whole thing.

Did I do something wrong?  i.e. are the configs wrong?

Why wouldn't the slave be "quiet", given that no data had changed, or is it
expected that the slaves will generally be busy, constantly checking on the
master?

If there was contextCSN of the max entryCSN time in a newly slapadd'd database,
would this result in less busy slaves after a reload?

Under slurpd, I would usually slapcat the master and slave and compare them to
be assured that updates have been working fine, but maybe syncrepl won't let me
do that, given all the differences between master and slave, but maybe those
differences are due to my configuration problems...