Вопрос по реплике/производительности

[vetedie]

Добрый день.
Наблюдаю проблему с openLDAP следующего характера.
Есть некоторый скрипт, который создает пользователей в базу. База настроена на wt. И она же реплицируется на соседний такой-же сервер.
Репликация n-way master. Все отлично, все работает, пользователи реплицируются.
Но, в один прекрастный момент, когда записано более 60к пользователей - реплика останавливается. Причем без каких-то криминальных записей в логах.
Запись на первый сервер продолжается.
После его перезагрузки - получатель продолжает догонять поставщика. Иногда ldapsearch достучаться можно. Иногда нет.
Подскажите, в какую сторону копать?

[egor]

Здравствуйте!
back-wt -- экспериментальный механизм, в мире с ним работает немного людей, а на русскоязычном пространстве, подозреваю, Вы единственный =) . Со временем ситуация изменится, но пока так. Первопроходцам -- стрелы, поселенцам -- урожай =) .

По существу: с такими специфичными вопросами лучше, наверное, обратиться к разработчику, например, оставить issue на github.

Будет здорово, если Вы будете держать нас в курсе ситуации.

Егор

[vetedie]

Т.е. это процентов на 99% проблема в wt, как в бекенде? Т.е. это не может быть какая-то проблема в самой лдап или в его библиотеке синхронизации?

[egor]

Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена (по крайней мере с mdb), в прежних версиях были проблемы. Вообще, я попрошу Леонида Юрьева посмотреть Ваш вопрос, возможно, он что-то подскажет (у него большой опыт борьбы с репликацией =) ) .

Егор

[Леонид Юрьев]

> Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена

Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена (по крайней мере с mdb), в прежних версиях были проблемы. Вообще, я попрошу Леонида Юрьева посмотреть Ваш вопрос, возможно, он что-то подскажет (у него большой опыт борьбы с репликацией =) ) .

Егор, спасибо за приглашение.

1) Про репликацию.
Ни в одной из версий OpenLDAP репликация полноценно не работает. Причем чем старее версия, тем страшнее баги...
С multi-master (aka n-way) у OpenLDAP есть несколько принципиальных проблем.
Кратко они перечислены и пояснены на слайдах https://ldapcon.org/2017/reopenldap/
Еще пару раз пояснял тут и на linux.org.ru. Если будут конкретный вопросы, то могу ответить.
Обращаю внимание - в OpenLDAP может случится массивное удаление данных, вплоть до полной вычисти всего replication scope!!!
Короче, если нужен multi-master, то только ReOpenLDAP.

2) Про WiredTiger backend.
Он экспериментальный и точно не готов для использования, также как и SQL-backend.
Там достаточно ошибок и недочетов: использование не-инициализированных данных, игнорирование или неверная обработка ошибок и т.д.
Если у вас есть какие-то веские причины использовать wt, то нужно брать ReOpenLDAP и добиваться работы всех тестов в нагрузочно-паралельном режиме (например посредством https://github.com/leo-yuriev/ReOpenLDAP/blob/devel/build/ci/buzz.sh).
Кроме этого, я могу дать скрипты для нагрузочной проверки multi-master репликации.
Если же вы не готовы приложить описанные усилия, то не морочьте голову и переключайтесь на MDBX (mdb) в ReOpenLDAP.

На всякий - на мой взгляд у WiredTiger нет никаких преимуществ перед https://github.com/leo-yuriev/libmdbx для LDAP-сценариев.

[vetedie]

Леонид, спасибо за оперативный ответ.
Подскажите, у вас сборка пакетов стандартная? Т.е. нет никаких подводных камней или спец.опций, не изложенных в доке?

[vetedie]

> Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена

Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена (по крайней мере с mdb), в прежних версиях были проблемы. Вообще, я попрошу Леонида Юрьева посмотреть Ваш вопрос, возможно, он что-то подскажет (у него большой опыт борьбы с репликацией =) ) .

Егор, спасибо за приглашение.

1) Про репликацию.
Ни в одной из версий OpenLDAP репликация полноценно не работает. Причем чем старее версия, тем страшнее баги...
С multi-master (aka n-way) у OpenLDAP есть несколько принципиальных проблем.
Кратко они перечислены и пояснены на слайдах https://ldapcon.org/2017/reopenldap/
Еще пару раз пояснял тут и на linux.org.ru. Если будут конкретный вопросы, то могу ответить.
Обращаю внимание - в OpenLDAP может случится массивное удаление данных, вплоть до полной вычисти всего replication scope!!!
Короче, если нужен multi-master, то только ReOpenLDAP.

2) Про WiredTiger backend.
Он экспериментальный и точно не готов для использования, также как и SQL-backend.
Там достаточно ошибок и недочетов: использование не-инициализированных данных, игнорирование или неверная обработка ошибок и т.д.
Если у вас есть какие-то веские причины использовать wt, то нужно брать ReOpenLDAP и добиваться работы всех тестов в нагрузочно-паралельном режиме (например посредством https://github.com/leo-yuriev/ReOpenLDAP/blob/devel/build/ci/buzz.sh).
Кроме этого, я могу дать скрипты для нагрузочной проверки multi-master репликации.
Если же вы не готовы приложить описанные усилия, то не морочьте голову и переключайтесь на MDBX (mdb) в ReOpenLDAP.

На всякий - на мой взгляд у WiredTiger нет никаких преимуществ перед https://github.com/leo-yuriev/libmdbx для LDAP-сценариев.

Ну на тестах запустили. Будем смотреть сейчас на прокачку 200к записей в базу.
И еще такой момент подскажите - в гите, где у вас лежит ReOpenLDAP - там уже движок хранения mdbx? --enable-mdb включает его? Или нужны какие-то дополнительные действия по его интеграции?

[Леонид Юрьев]

Ну на тестах запустили. Будем смотреть сейчас на прокачку 200к записей в базу.
И еще такой момент подскажите - в гите, где у вас лежит ReOpenLDAP - там уже движок хранения mdbx? --enable-mdb включает его? Или нужны какие-то дополнительные действия по его интеграции?

Да, движок уже внутри https://github.com/leo-yuriev/ReOpenLDAP/tree/devel/libraries/libmdbx (вставлен посредством git subtee).

Да, --enable-mdb включает его.
В целом, по историческим причинам, mdbx внутри ReOpenLDAP виден как LMDB/mdb.
Дополнительные опции описаны в man-страницах.

На всякий уточню про wt-backend.
В своей версии (https://github.com/osstech-jp/openldap) японцы много чего доледали/исправили.
Поэтому она гораздо более работоспособна чем оригинальный OpenLDAP.
Тем не менее, они доработаювают только wt-backend.
Соответственно все баги в самом OpenLDAP остались как есть.
Предполагаю что проблемы с репликацией у вас именно из-за них.

Я предложил им влиться в ReOpenLDAP (https://github.com/osstech-jp/openldap/issues/6), но пока молчат.
Тем не менее, я думаю взять все их доработки wt-бэкенда в ReOpenLDAP.

[vetedie]

Ну на тестах запустили. Будем смотреть сейчас на прокачку 200к записей в базу.
И еще такой момент подскажите - в гите, где у вас лежит ReOpenLDAP - там уже движок хранения mdbx? --enable-mdb включает его? Или нужны какие-то дополнительные действия по его интеграции?

Да, движок уже внутри https://github.com/leo-yuriev/ReOpenLDAP/tree/devel/libraries/libmdbx (вставлен посредством git subtee).

Да, --enable-mdb включает его.
В целом, по историческим причинам, mdbx внутри ReOpenLDAP виден как LMDB/mdb.
Дополнительные опции описаны в man-страницах.

На всякий уточню про wt-backend.
В своей версии (https://github.com/osstech-jp/openldap) японцы много чего доледали/исправили.
Поэтому она гораздо более работоспособна чем оригинальный OpenLDAP.
Тем не менее, они доработаювают только wt-backend.
Соответственно все баги в самом OpenLDAP остались как есть.
Предполагаю что проблемы с репликацией у вас именно из-за них.

Я предложил им влиться в ReOpenLDAP (https://github.com/osstech-jp/openldap/issues/6), но пока молчат.
Тем не менее, я думаю взять все их доработки wt-бэкенда в ReOpenLDAP.

По wt-backend было бы прикольно. Не зря же его монго взяло, как базовый.
И еще раз огромное спасибо за оперативные ответы.

Реплика на 200к прошла без проблем. Единственное, в логи постоянно валится syncrepl_process: rid=003 (-45) Unknown API error
по которому я пока информацию найти не смог. ( Но думаю - это дело наживное.

[Леонид Юрьев]

По wt-backend было бы прикольно. Не зря же его монго взяло, как базовый.
И еще раз огромное спасибо за оперативные ответы.

У Монго всё было достаточно плохо и безпросветно.
Как только M$ поняли это - решили прикупить движок хранения.
Но не суть, дело в другом.

Для LDAP характерна нагрузка по чтению/поиску, с относительно редкими записями.
Поэтому WT c LSM внутри тут совершенно не у дел.
При нагрузке по чтению MDBX (и LMDB) уделает в разы любой LSM, не только WT, но и RocksDB, Sophia, Vynil из Tarantool и т.д.
Для примера http://bit.ly/2mvaJEN

Но и при большой нагрузке по записи/обновлению MDBX может достаточно много.
Особенно если данные помещаются в память и на фоне апдейтов данных нужно держать высокую нагрузку по чтению.
В такой ситуации от LSM-движков можно ожидать глюков, дребезга и "замирания", а для MDBX достаточно быстрого SSD и/или контроллера с Write-Back кэшем на батарейке.
Поэтому в МегаФон под нагрузкой работает MDBX и ReOpenLDAP, а не WT или RocksDB.
Грубо говоря, MDBX как АК-47 - стреляет пака есть патроны...

Реплика на 200к прошла без проблем. Единственное, в логи постоянно валится syncrepl_process: rid=003 (-45) Unknown API error
по которому я пока информацию найти не смог. ( Но думаю - это дело наживное.

Да, это мелкая забытая оплошность. Не ошибка, можете смело игнорировать.
Поправил в devel-ветке = https://github.com/leo-yuriev/ReOpenLDAP/commit/999ee68f1c3027a7448627b35bef86e63bc356ec

[vetedie]

Леонид, а подскажите такой практический вопрос.

С репликой все хорошо, она живая и не разваливается на огромных объемах.
Но обнаружили другой момент.
Юзаем ее для базы в размере 2590000 записей (два с половиной миллиона). В одиночную базу записывается достаточно быстро (там у нас импортируется скриптом) за 22-24 часа.
А вот потом дальнейшая синхронизация с другим сервером - первые миллиона полтора идут быстро.
А потом начинает скорость падать и падать до 400 записей за 5 минут.
И очень сильно растет нагрузка на жесткие диски.

Несмотря на виртуализацию, ресурсы выделены достаточные. Проц практически не нагружается.
Что бы вы могли посоветовать в данном вопросе?

[Леонид Юрьев]

Леонид, а подскажите такой практический вопрос.

С репликой все хорошо, она живая и не разваливается на огромных объемах.
Но обнаружили другой момент.
Юзаем ее для базы в размере 2590000 записей (два с половиной миллиона). В одиночную базу записывается достаточно быстро (там у нас импортируется скриптом) за 22-24 часа.
А вот потом дальнейшая синхронизация с другим сервером - первые миллиона полтора идут быстро.
А потом начинает скорость падать и падать до 400 записей за 5 минут.
И очень сильно растет нагрузка на жесткие диски.

Несмотря на виртуализацию, ресурсы выделены достаточные. Проц практически не нагружается.
Что бы вы могли посоветовать в данном вопросе?

Во-первых, советую включить limit-concurrent-refresh. Посмотрите описание этой опции в man-страницах.

Во-вторых, у MDBX/LMDB нет WAL и из-за этого относительно большой WAF (эта особенность является плюсом одних ситуациях и минусом в других).
Проще говоря, любое обновление одной записи породит Olog(N) обновлений в файле БД на диске.
Поэтому "направление выхода" одно - не фиксировать на диске каждое изменение отдельно, а делать пакетную или "ленивую" запись.

С практической точки зрения вам нужно для mdb-бэкенда использовать опции: utterly-nosync (не описана в man), nosync, writemap, nometasync и расширенный вариант checkpoint, что позволит сбрасывать данные на диск с задаваемым периодом и/или по объему накопившихся изменений.

В третьих, если у вас система хранения (дисковый контроллер) с write-back кэшем "на батарейке", то может сильно помочь опция "lifo" mdb-бэкенда.

В четвертых, вы можете менять режим работы БД в некоторых пределах "на лету" (без перезагрузки сервере через config-бэкенд).
Т.е. выключать синхронную фиксацию на диске на время заливки данных и первоначальной синхронизации, а потом включать обычный "безопасный" режим.
Такое переключение достаточно штатный подход, тем не менее в коде было очень много изменений, после того как такое переключение тестировали под нагрузкой в мегафоновских масштабах.
Поэтому лучше сначала проверить на стенде.

---

Для понимания терминов WAL, WAF и особенностей MDBX/LMDB советую пару раз прочесть https://github.com/leo-yuriev/libmdbx/blob/master/README-RU.md, там есть ссылки и пояснения относительно nosync-опций.
Кроме этого есть можно глянуть записи моих докладов  затрагивающих тему MDBX/LMDB/libmdbx.
Если не ошибаюсь на youtube доступна запись 2015 c Highload++, а у Стаса Фомина на http://0x1.tv есть записи с Alt-овых конференций.

[vetedie]

Спасибо за оперативный ответ.
Будем изучать документацию дальше.

Пока что на тесте решили проблему относительно реплики тюнингом файловой системы. Мы используем zfs. Достаточно оказалось выключить atime в делегированном датасете с базой и увеличить zfs_rec_size (он же ZFS Record Size) до максимального.
В принципе, то что догонялось в течении 3 суток оперативно вылилось за 10 часов, что нас устраивает.
Сейчас докинем третьего участника и будем сравнивать.