--On Thursday, October 20, 2016 10:19 AM +0200 Raffael Sahli public@raffaelsahli.com wrote:
Hi
What can lead a consumer to "randomly" delete ~50% of all objects in his database? I have this problem now for ~1-2months and on 3 different master/slave groups.
The consumer starts to delete objects (but those are all present on the master):
Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 19 17:16:22 ldap-slave002.xxx
This is not delta-syncrepl, this is syncrepl. What triggered your system to fall back to syncrepl?
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 10/25/2016 03:26 AM, Quanah Gibson-Mount wrote:
--On Thursday, October 20, 2016 10:19 AM +0200 Raffael Sahli public@raffaelsahli.com wrote:
Hi
What can lead a consumer to "randomly" delete ~50% of all objects in his database? I have this problem now for ~1-2months and on 3 different master/slave groups.
The consumer starts to delete objects (but those are all present on the master):
Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 19 17:16:22 ldap-slave002.xxx
This is not delta-syncrepl, this is syncrepl. What triggered your system to fall back to syncrepl?
Tell me, I really don't know.
Is this as designed? Syncrepl as fall back mechanism if delta-syncrepl failed? (But I don't know why delta-synrepl failed, how can I verify that delta-syncrepl does work properly)
However this should not happen with syncrepl anyways. How can it be that I have only 23 objects left on my consumer after a full re sync with thousands of objects?
--Quanah
openldap-technical@openldap.org