История небольшого успеха с PostgreSQL – Владимир Бородин
1 like2,592 views
Документ описывает успешный опыт использования PostgreSQL для управления большими объемами данных и нагрузками, включая шардирование, отказоустойчивость и мониторинг. В нем обсуждаются проблемы, с которыми столкнулись при реализации, а также достигнутые результаты, такие как 2+ ТБ данных и 40K запросов в секунду. Заключение подчеркивает полезный опыт для администраторов баз данных и положительное восприятие PostgreSQL в сообществе.
История небольшого успеха с PostgreSQL – Владимир Бородин
- 2. История небольшого успеха с PostgreSQL Владимир Бородин Системный администратор
- 3. 3 Коротко • Про сборщики • Масштабирование • Отказоустойчивость • Мониторинг • Проблемы • Итоги
- 4. Про сборщики
- 5. 5 Что это?
- 6. 6 Как это было? • Все метаданные в oracle • Шардирование по пользователям на стороне другого сервиса • Все запросы только в мастер • Сборщик работает с чанком из 1000 заданий • Чанки распределяются между сборщиками с помощью хранимой логики в базе
- 7. 7 Почему сборщики? • Легко отчуждаемы – Нет взаимосвязей с другими данными в oracle • Наименее критичный по SLA сервис – Имеет право не работать единицы минут • Ощутимые объём данных и нагрузка – 2+ ТБ данных и ~40k rps
- 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
- 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. Владимир Бородин Системный администратор [email protected] +7 495 739-70-00 (доб. 7255) 119021, Москва, ул. Льва Толстого, 18Б Спасибо