[Date Prev][Date Next]
Re: syncrepl openldap-2.3.17
Allan E. Johannesen wrote:
I did a slapadd of a database to the master, with this in the config:
syncprov-checkpoint 10 10
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
in the config, resulted in a pretty busy slave server after both slapd's were
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?
Configs are probably fine, use slapadd -w when using syncrepl. Read the
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
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?
Yes, the contextCSN is needed on both the provider and the consumers.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/