Univention Bugzilla – Bug 43046
algorithm in listener to choose replication partner seems to be not "random"
Last modified: 2019-01-03 07:19:39 CET
In a project with >30 DC Slave and memberserver connecting to 3 DC Backups we see that most listeners connect to one of those Backups. So in phases of higher replication load the DC Backup is "overloaded" and most DC Slaves have a replication delay. We should review the process, either the current implementation is not real "random", or the likelihood that most clients connect to one server is too high. A workaround might be the implementation of #35165
UDL evaluates the UCRV "ldap/backup", which is managed by "management/univention-directory-listener/python/ldap_server.py". It *only uses DC Backup*s (and the DC Master), *never any DC Slave*. See <http://docs.software-univention.de/developer-reference-4.1.html#listener:procedure> The description also only talks about Backups, not Slaves: >[ldap/backup] >Description[de]=Der/die Domänencontroller Backup-Systeme der Domäne. Mehrfache Einträge müssen mit Leerzeichen getrennt werden. >Description[en]=The backup domain controller system(s) in the domain. Multiple entries need to be separated by blanks. So currently: Works-as-documented(-and-intended?)
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.