Dear all,
We have an OpenLDAP 2.4 cluster of three nodes configured in multi-master and accessed through a VIP in round-robin. The three machines run RHEL7.
We noticed that deletion of an entry (done from a Windows machine onto the first node via Oracle's tool ldapmodify.exe) takes a long time (about 48 hours) to be replicated in the cluster.
Here's the relevant extract of cn=config for the first node:
olcSyncrepl: {0}rid=001 provider=ldap://mynode2:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcSyncrepl: {1}rid=002 provider=ldap://mynode3:389/ bindmethod=simple binddn="cn=Replicator,dc=mydomain,dc=org" credentials=1234567890 searchbase="dc=mydomain,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 +" keepalive="60:5:10" olcMirrorMode: TRUE
We looked up for the offending entry (thisentry) in all nodes' logs and we found this line on mynode3:
Jun 18 14:18:20 mynode3 slapd[8871]: conn=1987936 op=14 DEL dn="dc=thisentry,ou=myou,ou=foobars,dc=mydomain,dc=org"
There are no other references to thisentry (apart from SRCH operations) on node1 and node2, even if the entry was originally deleted from node1, as said above.
What could be the cause and what could we do to further troubleshoot the issue? Thanks in advance.
--On Wednesday, June 26, 2019 5:16 PM +0000 x0101 x0101@protonmail.com wrote:
We have an OpenLDAP 2.4 cluster of three nodes configured in multi-master and accessed through a VIP in round-robin. The three machines run RHEL7.
What could be the cause and what could we do to further troubleshoot the issue? Thanks in advance.
a) Don't use the outdated builds from RedHat. You generally have the following choices here: 1) Build OpenLDAP yourself 2) Use a free replacement, such as Symas' OpenLDAP for Linux (https://repo.symas.com/sofl/rhel7/) or the LTB project's OpenLDAP build (https://ltb-project.org/documentation/openldap-rpm#yum_repository) 3) Obtain a commercially supported version of OpenLDAP, such as Symas OpenLDAP Gold (https://symas.com/symasopenldap/. There is also optional commerical support for Symas OpenLDAP for Linux
b) Use delta-syncrepl, not standard syncrepl.
c) Ensure that in addition to stats logging you also have sync logging enabled, otherwise you'll never be able to tell what's occuring.
Also, you fail to note your configuration settings for the syncprov overlay, which is rather critical to note as well. For example, you may have a low sessionlog value set, which can cause all sorts of havoc with standard syncrepl, especially in older releases.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org