On 10/27/2016 08:35 PM, Quanah Gibson-Mount wrote:
--On Wednesday, October 26, 2016 10:07 AM +0200 Raffael Sahli public@raffaelsahli.com wrote:
This is not delta-syncrepl, this is syncrepl. What triggered your system to fall back to syncrepl?
Tell me, I really don't know.
I can't tell you, it would be in your logs.
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)
Correct, if there is an issue, things will fall back to syncrepl. Again, you'd have to look at your logs to determine why it fell back.
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?
Because syncrepl can be buggy?
This problem is now on all our master/consumer environments. Start slave with empty db, resync all objects. done. Minutes later the objects are gone and it is completely random. Sometimes there are no objects left and sometimes there are a few left.
I've tried different configurations, upgrade os & recompile, downgrade slapd to 2.4.43 but problem is still there.
Had to shutdown all slaves, all traffic is now on the master nodes, probably gonna try out reopenldap, its more or less the only shot I have left.
I've managed to capture the logs at the time the consumer starts to delete objects within debug mode -1, if anybody is willing to see it. I'm not an OpenLDAP dev and can not make out any problems.
I have no clue what changed that we have now such problems. What else is related to (delta)-syncrepl? time? Could it be wrong/strange slapd configurations? (acl, limits, syncrepl,...) But actually not much changed and the sync does work for some time...
Cheers
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com