Full_Name: Andrew Findlay Version: 2.4.23 OS: SLES 10.3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.97.25.132)
The attribute uniqueness overlay can cause syncrepl to jam up. Consider this case:
1) Configure a mirrormode pair with identical configs, including 'unique_attributes uid'
2) Start one server and add some data, including an entry containing a UID value.
3) Start the second server, let it synchronise, then stop it again.
4) On the first server, delete the entry and add a new one with a different DN that has the same UID value.
5) Start the second server. Look in the logs, and you will see something like this:
Sep 7 11:33:03 jupiter slapd[19407]: @(#) $OpenLDAP: slapd 2.4.23 (Sep 6 2010 19:55:47) $ andrew@jupiter:/usr/local/src/openldap-2.4.23/servers/slapd Sep 7 11:33:03 jupiter slapd[19408]: slapd starting Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 ACCEPT from IP=127.0.0.1:33611 (IP=0.0.0.0:389) Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 BIND dn="" method=128 Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=0 RESULT tag=97 err=0 text= Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 op=2 UNBIND Sep 7 11:33:04 jupiter slapd[19408]: conn=1000 fd=23 closed Sep 7 11:33:04 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:33:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:33:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) Sep 7 11:34:04 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:34:04 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:34:04 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left) Sep 7 11:35:05 jupiter slapd[19408]: null_callback : error code 0x13 Sep 7 11:35:05 jupiter slapd[19408]: syncrepl_entry: rid=001 be_add uniqueIdentifier=list.6b9432f9,dc=routing,dc=mail,dc=apps,dc=nis,dc=brunel,dc=ac,dc=uk failed (19) Sep 7 11:35:05 jupiter slapd[19408]: do_syncrepl: rid=001 rc 19 retrying (9 retries left)
The problem is that syncrepl is trying to add the new entry before deleting the old one, and the uniqueness constraint on UID is preventing it from doing so.
It is likely that other constraints on data will have the same effect. See for example this thread: http://www.openldap.org/lists/openldap-software/201001/msg00038.html
The obvious answer is for syncrepl to bypass all data checks, as the supplier server should have already enforced them. The problem with that is that clients could see data that breaks the rules if they query while syncrepl is running (unless the refresh phase is handled as a single transaction and thus isolated from clients until it is complete).
Andrew