6. 6
Как это было?
• Все метаданные в oracle
• Шардирование по пользователям на
стороне другого сервиса
• Все запросы только в мастер
• Сборщик работает с чанком из 1000
заданий
• Чанки распределяются между сборщиками с
помощью хранимой логики в базе
7. 7
Почему сборщики?
• Легко отчуждаемы
– Нет взаимосвязей с другими данными в
oracle
• Наименее критичный по SLA сервис
– Имеет право не работать единицы минут
• Ощутимые объём данных и нагрузка
– 2+ ТБ данных и ~40k rps
10. 10
PLProxy
• Положительный опыт у ребят из Skype
• Нет необходимости в костылях для
шардирования в другом сервисе
• Больший контроль в руках DBA
• Более простой вариант смены СУБД для
приложения
– Шардирование и отказоустойчивость
– Хранимая логика в базе
11. 11
• Шардирование по диапазонам ключей
• Ключи из sequence'ов, которые на конечных
базах разные
• При добавлении нового шарда мастер
конечной базы:
– через FDW заносит информацию на
pgmeta
– меняет sequence'ы
• Эта информация доезжает до всех plproxy-
машин
PLProxy
13. 13
pgcheck
• Назначает приоритеты машинам конечных
баз в зависимости от:
– Живости машины,
– Её роли (мастер/реплика),
– В случае реплик:
• Удалённости (ЦОД),
• (А)синхронности,
• Нагрузки,
• TODO: отставания.
• Это меняет поведение функции
plproxy.get_cluster_partitions
15. 15
pgswitch
• Скрипт для планового переключения
мастера, запускаемый на реплике
• Проверяет всё, что можно и нужно, на
старом и новых мастерах
• Переключает мастера и все реплики на
нового мастера
• В любой непонятной ситуации паникует
16. 16
pgsync
• Живёт на конечных базах
• Меняет репликацию с синхронной на
асинхронную и обратно
• Автоматическое переключение мастера без
потери данных
• Пока только в тестинге
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
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 с таймаутами
27. 27
• 2+ ТБ данных (15+ млрд. строк)
• 40000+ rps
• ~ -1 oracle
• ~ 6 месяцев 0,5 человека
• Хорошее начало светлого пути:
– Много полезного опыта для DBA
– Много переиспользуемого кода для
разработчиков
– Положительное мнение о PostgreSQL у
всех :)
Итоги
