Hello,
I am now facing a new issue which could well be due to me but I need to be sure. I have set a new slave running 2.4.17 on Debian whilst the master is a 2.3.43 running on FreeBSD 6.4. I have observed a similar behavior on a slave running 2.3.43 also on FreeBSD.
That behavior is that when you start an empty database, syncrepl starts copying the content but usually stops after a while (ie. copies only part of the database but far from all objects).
Is it recommended to slapcat the objects when setting up a new slave or is syncrepl able to do that by itself?
This is my syncrepl rules:
syncrepl rid=124 \ provider=ldaps://masterldap.example.com:636 \ type=refreshAndPersist \ searchbase="dc=example,dc=com" \ scope=sub \ filter="(objectClass=*)" \ attrs="*" \ schemachecking=off \ tls_cacert=/etc/ldap/cert/cacert.pem \ binddn="cn=ldaprep,dc=example,dc=com" \ credentials=xxxxxx
Cheers, Steph
On 05/11/2009 10:03, FRLinux wrote:
Hello,
I am now facing a new issue which could well be due to me but I need to be sure. I have set a new slave running 2.4.17 on Debian whilst the master is a 2.3.43 running on FreeBSD 6.4. I have observed a similar behavior on a slave running 2.3.43 also on FreeBSD.
That behavior is that when you start an empty database, syncrepl starts copying the content but usually stops after a while (ie. copies only part of the database but far from all objects).
Is it recommended to slapcat the objects when setting up a new slave or is syncrepl able to do that by itself?
Syncrepl is able to do that by itself. If your database is particularly large, you might want to slapcat / slapadd to a slave to improve performance, but that's not a requirement.
This is my syncrepl rules:
syncrepl rid=124 \ provider=ldaps://masterldap.example.com:636 \ type=refreshAndPersist \ searchbase="dc=example,dc=com" \ scope=sub \ filter="(objectClass=*)" \ attrs="*" \
attrs="*" means "only replicate user attributes, not operational attributes". If you want to replicate your database, you need operational attributes too. The default for "attrs" is generally fine.
schemachecking=off \ tls_cacert=/etc/ldap/cert/cacert.pem \ binddn="cn=ldaprep,dc=example,dc=com" \ credentials=xxxxxx
Cheers, Steph
On Thursday 05 November 2009 04:03:09 FRLinux wrote:
Hello,
I am now facing a new issue which could well be due to me but I need to be sure. I have set a new slave running 2.4.17 on Debian whilst the master is a 2.3.43 running on FreeBSD 6.4. I have observed a similar behavior on a slave running 2.3.43 also on FreeBSD.
That behavior is that when you start an empty database, syncrepl starts copying the content but usually stops after a while (ie. copies only part of the database but far from all objects).
Is it recommended to slapcat the objects when setting up a new slave or is syncrepl able to do that by itself?
This is my syncrepl rules:
syncrepl rid=124 \ provider=ldaps://masterldap.example.com:636 \ type=refreshAndPersist \ searchbase="dc=example,dc=com" \ scope=sub \ filter="(objectClass=*)" \ attrs="*" \ schemachecking=off \ tls_cacert=/etc/ldap/cert/cacert.pem \ binddn="cn=ldaprep,dc=example,dc=com" \ credentials=xxxxxx
Cheers, Steph
Check your limits on the master (sizelimit and/or timelimit). The slave is still subject to the limits which are in effect on the master. I ran into that issue too at the beginning.
Karsten.
FRLinux frlinux@gmail.com writes:
Hello,
I am now facing a new issue which could well be due to me but I need to be sure. I have set a new slave running 2.4.17 on Debian whilst the master is a 2.3.43 running on FreeBSD 6.4. I have observed a similar behavior on a slave running 2.3.43 also on FreeBSD.
That behavior is that when you start an empty database, syncrepl starts copying the content but usually stops after a while (ie. copies only part of the database but far from all objects).
Is it recommended to slapcat the objects when setting up a new slave or is syncrepl able to do that by itself?
This is my syncrepl rules:
syncrepl rid=124 \ provider=ldaps://masterldap.example.com:636 \ type=refreshAndPersist \ searchbase="dc=example,dc=com" \ scope=sub \ filter="(objectClass=*)" \ attrs="*" \ schemachecking=off \ tls_cacert=/etc/ldap/cert/cacert.pem \ binddn="cn=ldaprep,dc=example,dc=com" \ credentials=xxxxxx
Set proper limits on provider and consumer, otherwise the default limit settings are applicable to cn=ldaprep,dc=example,dc=com.
-Dieter
On Thu, Nov 5, 2009 at 4:39 PM, Dieter Kluenter dieter@dkluenter.de wrote:
Set proper limits on provider and consumer, otherwise the default limit settings are applicable to cn=ldaprep,dc=example,dc=com.
Hello,
I am responding to myself about this problem that i got time to work on only today. The fix was to set the following in the producer slapd.conf:
timelimit unlimited sizelimit unlimited
After some digging, i found that it blocked precisely at the 500 record.
Cheers, Steph
--On Tuesday, December 08, 2009 1:16 PM +0000 FRLinux frlinux@gmail.com wrote:
timelimit unlimited sizelimit unlimited
What you are probably really after is the "limits" directive, so that you only set these things to unlimited for your replication user, not every user.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org