В докладе речь пойдёт о том, как в Яндекс.Почту для хранения метаданных сборщиков внедрили PostgreSQL. Владимир расскажет, зачем и почему это сделали и каким образом решили масштабироваться. А также о репликации и средствах обеспечения отказоустойчивости, о возникших проблемах и способах их решения.

2. История
небольшого успеха
с PostgreSQL
Владимир Бородин
Системный администратор

3. 3
Коротко
• Про сборщики
• Масштабирование
• Отказоустойчивость
• Мониторинг
• Проблемы
• Итоги

4. Про сборщики

5. 5 Что это?

6. 6
Как это было?
• Все метаданные в oracle
• Шардирование по пользователям на
стороне другого сервиса
• Все запросы только в мастер
• Сборщик работает с чанком из 1000
заданий
• Чанки распределяются между сборщиками с
помощью хранимой логики в базе

7. 7
Почему сборщики?
• Легко отчуждаемы
– Нет взаимосвязей с другими данными в
oracle
• Наименее критичный по SLA сервис
– Имеет право не работать единицы минут
• Ощутимые объём данных и нагрузка
– 2+ ТБ данных и ~40k rps

8. Масштабирование

9. 9 Общая схема

10. 10
PLProxy
• Положительный опыт у ребят из Skype
• Нет необходимости в костылях для
шардирования в другом сервисе
• Больший контроль в руках DBA
• Более простой вариант смены СУБД для
приложения
– Шардирование и отказоустойчивость
– Хранимая логика в базе

11. 11
PLProxy
• Шардирование по диапазонам ключей
• Ключи из sequence'ов, которые на конечных
базах разные
• При добавлении нового шарда мастер
конечной базы:
– через FDW заносит информацию на
pgmeta
– меняет sequence'ы
• Эта информация доезжает до всех plproxy-
машин

12. Отказоустойчивость
• pgcheck
• pgswitch
• pgsync

13. 13
pgcheck
• Назначает приоритеты машинам конечных
баз в зависимости от:
– Живости машины,
– Её роли (мастер/реплика),
– В случае реплик:
• Удалённости (ЦОД),
• (А)синхронности,
• Нагрузки,
• TODO: отставания.
• Это меняет поведение функции
plproxy.get_cluster_partitions

14. 14 Деградация в read-only в случае потери мастера

15. 15
pgswitch
• Скрипт для планового переключения
мастера, запускаемый на реплике
• Проверяет всё, что можно и нужно, на
старом и новых мастерах
• Переключает мастера и все реплики на
нового мастера
• В любой непонятной ситуации паникует

16. 16
pgsync
• Живёт на конечных базах
• Меняет репликацию с синхронной на
асинхронную и обратно
• Автоматическое переключение мастера без
потери данных
• Пока только в тестинге

17. Мониторинг

18. 18
Проверки
pg-active-sessions | Количество активных сессий
pg-connections | Количество свободных соединений
pg-log-errors | Количество ошибок в журнале(-ах) за
последнюю минуту
pg-mounted-nfs | Смонтированность nfs-каталогов
pg-ping | SELECT 1 в PostgreSQL
pg-replication-alive | Количество живых реплик
pg-replication-lag | Лаг реплики в байтах
pg-vacuum | Время последнего vacuum/analyze для
всех таблиц
pg-xlog-files | Количество незаархивированных xlog'ов
pgbouncer | TCP chat на порт 6432 на каждой
машине
yrpop-errors | Количество ошибок ymod_pq в yrpop.log

19. 19
Графики
• Начинали с pg_stats_reporter
• Сейчас ищем ему замену
• И почти всё рисуем в graphite

20. 20 Пример дашборда

21. Проблемы

22. 22
По первости
• По привычке отрезали много памяти под
shared_buffers
• Много оптимизировали дисковую
подсистему
– raid'ы с файловыми системами
– page cache
– Checkpoints/autovacuum/bgwriter

23. 23
RUN ON ALL
• Шардирование сделали по
идентификаторам сборщика и чанка
• Сборщики одного пользователи могут
попадать в разные шарды
• Запрос “покажи мне все сборщики
конкретного пользователя” вынужден
выполняться с RUN ON ALL
• Начинали с 32 (!) логических шардов
• Запрос оказался весьма частым
• Наедались соединениями

24. 24
RUN ON ALL
• Не стоит использовать для частых запросов
• Сократили количество шардов с 32 до 4
• Закэшировали результаты этого запроса в
приложении

25. 25
Нам не хватает:
• Интерфейс ожиданий и трассировка сессии
• Возможность отдать под shared_buffers всю
память и включить O_DIRECT
• Нормальное партиционирование
• Полусинхронная репликация
• Параллелизм:
– Восстановление реплики
– pg_basebackup
– Другие операции
• Advisory locks с таймаутами

26. Итоги

27. 27
Итоги
• 2+ ТБ данных (15+ млрд. строк)
• 40000+ rps
• ~ -1 oracle
• ~ 6 месяцев 0,5 человека
• Хорошее начало светлого пути:
– Много полезного опыта для DBA
– Много переиспользуемого кода для
разработчиков
– Положительное мнение о PostgreSQL у
всех :)

28. Владимир Бородин
Системный администратор
d0uble@yandex-team.ru
+7 495 739-70-00 (доб. 7255)
119021, Москва, ул. Льва
Толстого, 18Б
Спасибо