Владимир БородинСистемный администратор
История небольшого успеха с PostgreSQL
3
Коротко
• Про сборщики
• Масштабирование
• Отказоустойчивость
• Мониторинг
• Проблемы
• Итоги
Про сборщики
5 Что это?
6
Как это было?
• Все метаданные в oracle
• Шардирование по пользователям на стороне другого сервиса
• Все запросы только в мастер
• Сборщик работает с чанком из 1000 заданий
• Чанки распределяются между сборщиками с помощью хранимой логики в базе
7
Почему сборщики?
• Легко отчуждаемы– Нет взаимосвязей с другими данными в oracle
• Наименее критичный по SLA сервис– Имеет право не работать единицы минут
• Ощутимые объём данных и нагрузка– 2+ ТБ данных и ~40k rps
Масштабирование
9 Общая схема
10
PL\Proxy
• Положительный опыт у ребят из Skype
• Нет необходимости в костылях для шардирования в другом сервисе
• Больший контроль в руках DBA
• Более простой вариант смены СУБД для приложения– Шардирование и отказоустойчивость– Хранимая логика в базе
11
• Шардирование по диапазонам ключей
• Ключи из sequence'ов, которые на конечных базах разные
• При добавлении нового шарда мастер конечной базы: – через FDW заносит информацию на pgmeta
– меняет sequence'ы
• Эта информация доезжает до всех plproxy-машин
PL\Proxy
Отказоустойчивость
• pgcheck
• pgswitch
• pgsync
13
pgcheck
• Назначает приоритеты машинам конечных баз в зависимости от:– Живости машины,– Её роли (мастер/реплика),– В случае реплик:
• Удалённости (ЦОД),• (А)синхронности,• Нагрузки,• TODO: отставания.
• Это меняет поведение функции plproxy.get_cluster_partitions
14 Деградация в read-only в случае потери мастера
15
pgswitch
• Скрипт для планового переключения мастера, запускаемый на реплике
• Проверяет всё, что можно и нужно, на старом и новых мастерах
• Переключает мастера и все реплики на нового мастера
• В любой непонятной ситуации паникует
16
pgsync
• Живёт на конечных базах• Меняет репликацию с синхронной на
асинхронную и обратно• Автоматическое переключение мастера без
потери данных• Пока только в тестинге
Мониторинг
18
pg-active-sessions | Количество активных сессийpg-connections | Количество свободных соединенийpg-log-errors | Количество ошибок в журнале(-ах) за последнюю минутуpg-mounted-nfs | Смонтированность nfs-каталоговpg-ping | SELECT 1 в PostgreSQLpg-replication-alive | Количество живых репликpg-replication-lag | Лаг реплики в байтахpg-vacuum | Время последнего vacuum/analyze для всех таблицpg-xlog-files | Количество незаархивированных xlog'овpgbouncer | TCP chat на порт 6432 на каждой машинеyrpop-errors | Количество ошибок ymod_pq в yrpop.log
Проверки
19
Графики
• Начинали с pg_stats_reporter• Сейчас ищем ему замену• И почти всё рисуем в graphite
20 Пример дашборда
Проблемы
22
По первости
• По привычке отрезали много памяти под shared_buffers
• Много оптимизировали дисковую подсистему– raid'ы с файловыми системами– page cache– Checkpoints/autovacuum/bgwriter
23
RUN ON ALL
• Шардирование сделали по идентификаторам сборщика и чанка
• Сборщики одного пользователи могут попадать в разные шарды
• Запрос “покажи мне все сборщики конкретного пользователя” вынужден выполняться с RUN ON ALL
• Начинали с 32 (!) логических шардов
• Запрос оказался весьма частым
• Наедались соединениями
24
RUN ON ALL
• Не стоит использовать для частых запросов
• Сократили количество шардов с 32 до 4
• Закэшировали результаты этого запроса в приложении
25
Нам не хватает:
• Интерфейс ожиданий и трассировка сессии
• Возможность отдать под shared_buffers всю память и включить O_DIRECT
• Нормальное партиционирование
• Полусинхронная репликация
• Параллелизм:– Восстановление реплики– pg_basebackup– Другие операции
• Advisory locks с таймаутами
Итоги
27
• 2+ ТБ данных (15+ млрд. строк)
• 40000+ rps
• ~ -1 oracle
• ~ 6 месяцев 0,5 человека
• Хорошее начало светлого пути:– Много полезного опыта для DBA– Много переиспользуемого кода для разработчиков
– Положительное мнение о PostgreSQL у всех :)
Итоги
Владимир Бородин
Системный администратор
+7 495 739-70-00 (доб. 7255)
119021, Москва, ул. Льва Толстого, 18Б
Спасибо