В Яндексе успешно заменили СУБД Oracle на PostgreSQL для сборщиков своей почты
12
Яндекс в качестве эксперимента в сервисе «Почта» провёл успешную замену одной из баз Oracle на свободную СУБД PostgreSQL для инструмента сборки электронной почты с других ящиков и продолжает работать в этом направлении.
На проходившей 24 сентября в Москве встрече сообщества «PostgreSQL в России» выступил с докладом Владимир Бородин, сотрудник компании «Яндекс». Тема его доклада — «История небольшого успеха с PostgreSQL». Владимир рассказал, почему решили уйти от Oracle и почему в качестве первого шага были выбраны именно сборщики, как выглядит решение и с какими трудностями пришлось столкнуться.
Было названо два основных мотива отказа от продукта Oracle: высокая цена и возможность решения ряда проблем только через поддержку компании с неопределёнными сроками. Обе ситуации могут решить свободные проекты, один из которых — PostgreSQL — и начали использовать в качестве эксперимента. Сборщики почты были выбраны по принципу минимизации ущерба в случае отказов и неудачного перехода. Основные причины выбора таковы: сборщики не были связаны с другими данными, некритичность простоя в течение нескольких минут и достаточный объём данных для тестирования.
Переход осуществлён на PostgreSQL 9.3 с использованием PL/Proxy. Самостоятельно в компании создали два инструмента и разрабатывают третий для повышения отказоустойчивости решения. Когда качество кода повысится, исходный код этих инструментов обещают открыть. Инструмент pgcheck размещается на прокси-серверах, опрашивает и анализирует состояние узлов и с помощью выставленных весов, регулирует нагрузку в шарде. Вторая утилита pgswitch — простой скрипт, который планово меняет мастера, чтобы не допустить деградации в режим «только для чтения» при потере мастера. Третий инструмент находится в тестовом режиме и получил название pgsync. Он размещается на конечных базах и может менять репликацию с синхронной на асинхронную и обратно, а также может автоматически переключать мастера без потери данных.
В целях мониторинга используется несколько проверок, в том числе количество активных сессий и свободных соединений, количество ошибок в логах за минуту и «живых» реплик, лаг реплики и т.д. Графики для мониторинга прорисовываются при помощи Graphite, а pg_stats_reporter при таких объёмах не справляется.
При переходе на PostgreSQL в Яндексе натолкнулись на следующие проблемы:
выделили много памяти под shared_buffer, что привело к большим пикам ввода/вывода при Checkpoint; много времени уделили оптимизации дисковой подсистемы; в новой схеме шардинга использовали 32 логических шарда, что привело к мультипликации одного запроса в прокси до 32 запросов к шардам (т.к. сборщики одного пользователя могли храниться на разных шардах и могли быть показаны только при запросе с RUN ON ALL на все 32 шарда). Из-за частого запроса «показать все сборщики пользователя» происходило переполнение соединениями в прокси. Также Владимир отмечает, что в PostgreSQL для целей компании не хватает ряда возможностей:
интерфейс ожиданий и трассировки сессии, как в Oracle; возможность выделить для shared_buffer всю память и включить O_DIRECT, как в Oracle или MySQL; нормальное партиционирование; полусинхронная репликация; параллелизм. По итогу доклада отмечается, что опыт перехода в целом оказался положительным и компания уже задействует PosgreSQL в других своих проектах. Подробнее с темой «История небольшого успеха с PostgreSQL» можно ознакомиться из записи доклада Владимира Бородина. Там же доступны слайды.
Постоянная ссылка к новости: http://www.nixp.ru/news/12845.html. Автор: Никита Лялин по материалам Яндекс.Мероприятия.
© nixp
