> У нас 6 мастер-мастер OpenLDAP разбросанный по всему миру (разные регионы). Трафик
> конечно не 10К апдейтов в секунду, но где-то чуть меньше половины.
> Собираем метрики, есть мониторинг - каких либо крупных проблем не наблюдаем.
> У вас есть пошаговая инструкция как воспроизвести эту проблему?

Как уже отвечал где-то рядом - достаточно зациклить собственные тесты OpenLDAP, которые тестируют репликацию.
Желательно на сильно загруженной машине.

Использовавшийся сценарий для проверки _примерно_ такой:
- на машине настраивается четыре local-interface, например 10.{1,2,3,4}.0.0.1/24
- конфигурируется full-mesh мультмастер кластер из 4-х инстанции slapd, т.е. у каждого slapd по 3 штуки syncprov и syncrepl к другим;
- все syncprov и syncrepl настраиваются так, чтобы работали через соответствующие local-интерфейсы, т.е. получает что каждый slapd "сидит" в своем сегменте 10.{1,2,3,4}.0.0.1/24;
- кроме этого каждый slapd слушает свой порт на 0.0.0.0;
- запускается питоновский скрипт, который стохастически начинает одновременно создавать/изменять/удалять записи через подключения ко всем четырем сервера (но при этом изменения не конфликтуют между собой);
- этот-же питоновский скрипт проверяет что данные соответствуют ожидаемым (можно создать, удалить, изменить и т.п.)
- запускается еще набор скриптов, который через iptables стохастически временно рвет syncprov-syncrepl соединения между узлами.
- оставляем "на ночь", утром проверяем что не упало и DIT на всех узлах совпадает.
- повторяем с ASAN и затем с Valgrind...

Если вы готовы разбираться со скриптами, то я наверное смогу их отыскать.

В OpenLDAP достаточно быстро всплывали ошибки:
- race conditions, use-after-free и всяческие падения в десятках мест;
- зацикливания и зависания;
- утечки памяти;
- воскрешение удаленных записей;
- удаление недавно добавленных и/или обновленных;

Удаление части replication scope более редкая ошибка, но внимательно прочитав RFC можно примерно догадаться когда и почему она происходит.