> 389DS не справляется с требуемой нагрузкой.Да, и в моём случае корень проблемы даже не столько в BDB как таковой (на чтении она всё равно в памяти, а массивная запись в LDAP — ???), сколько в механизме репликации (плагины changelog5, retro-changelog). Которые пишут в журнал т.ч. kerberos-аттрибуты типа "время последней авторизации этого аккаунта". В *OpenLDAP такой проблемы нет, по очевидной причине.
> Далее, после починки репликации в ReOpenLDAP, у меня есть сомнения что multi-master
> репликация в 389DS (и где-либо еще) работает на 100%. Там очень-очень
Да. Принимая соглашение multi-master, мы соглашаемся: 1. С (окончательной) потерей атомарности. 2. С возможностью навернуть репликацию, испортив журнал (и ещё 100500 увёрток мелким текстом). Прямо как у юристов. Но (иногда) с ней таки лучше. Если не делать, как M$-коллеги "а можно 50 m-m? можно! (утрирую, но не сильно)".
> Но это еще не все.
> https://pro-ldap.ru/tr/rfc/rfc4533.html - очень талантливый документ, можно легко сделать
> десяток реализаций в полном соответствии с ним, так что ни одна
> пара не сможет взаимодействовать. Поэтому примерно у всех LDAP-ов репликация/синхронизация
> работает только с сама-с-собой.
Вот для этого как раз и поставляются 100500 плагинов для 389. Включая (уродский) retro-changelog, на который (я) ругаюсь как раз по причине неадекватной нагрузки на запись. Но: позволяющий создавать/поддерживать всякие интерфейсы к чужим системам. См. реализацию ёж&уж (bind9-ldap).
* В OpenLDAP система плагинов — вообще кошмар полный. Ошибка в (любом) плагине рушит демона. By design. Зато в пустом OpenLDAP никто не путается под ногами, что (в моём окружении) даёт x2…x3 даже на BDB.
