Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

История небольшого успеха с PostgreSQL

https://simply.name/ru/video-pg-meetup-yandex.html

  • Login to see the comments

  • Be the first to like this

История небольшого успеха с PostgreSQL

  1. 1. Владимир Бородин Системный администратор История небольшого успеха с PostgreSQL
  2. 2. 3 Коротко • Про сборщики • Масштабирование • Отказоустойчивость • Мониторинг • Проблемы • Итоги
  3. 3. Про сборщики
  4. 4. 5 Что это?
  5. 5. 6 Как это было? • Все метаданные в oracle • Шардирование по пользователям на стороне другого сервиса • Все запросы только в мастер • Сборщик работает с чанком из 1000 заданий • Чанки распределяются между сборщиками с помощью хранимой логики в базе
  6. 6. 7 Почему сборщики? • Легко отчуждаемы – Нет взаимосвязей с другими данными в oracle • Наименее критичный по SLA сервис – Имеет право не работать единицы минут • Ощутимые объём данных и нагрузка – 2+ ТБ данных и ~40k rps
  7. 7. Масштабирование
  8. 8. 9 Общая схема
  9. 9. 10 PLProxy • Положительный опыт у ребят из Skype • Нет необходимости в костылях для шардирования в другом сервисе • Больший контроль в руках DBA • Более простой вариант смены СУБД для приложения – Шардирование и отказоустойчивость – Хранимая логика в базе
  10. 10. 11 • Шардирование по диапазонам ключей • Ключи из sequence'ов, которые на конечных базах разные • При добавлении нового шарда мастер конечной базы: – через FDW заносит информацию на pgmeta – меняет sequence'ы • Эта информация доезжает до всех plproxy- машин PLProxy
  11. 11. Отказоустойчивость • pgcheck • pgswitch • pgsync
  12. 12. 13 pgcheck • Назначает приоритеты машинам конечных баз в зависимости от: – Живости машины, – Её роли (мастер/реплика), – В случае реплик: • Удалённости (ЦОД), • (А)синхронности, • Нагрузки, • TODO: отставания. • Это меняет поведение функции plproxy.get_cluster_partitions
  13. 13. 14 Деградация в read-only в случае потери мастера
  14. 14. 15 pgswitch • Скрипт для планового переключения мастера, запускаемый на реплике • Проверяет всё, что можно и нужно, на старом и новых мастерах • Переключает мастера и все реплики на нового мастера • В любой непонятной ситуации паникует
  15. 15. 16 pgsync • Живёт на конечных базах • Меняет репликацию с синхронной на асинхронную и обратно • Автоматическое переключение мастера без потери данных • Пока только в тестинге
  16. 16. Мониторинг
  17. 17. 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 Проверки
  18. 18. 19 Графики • Начинали с pg_stats_reporter • Сейчас ищем ему замену • И почти всё рисуем в graphite
  19. 19. 20 Пример дашборда
  20. 20. Проблемы
  21. 21. 22 По первости • По привычке отрезали много памяти под shared_buffers • Много оптимизировали дисковую подсистему – raid'ы с файловыми системами – page cache – Checkpoints/autovacuum/bgwriter
  22. 22. 23 RUN ON ALL • Шардирование сделали по идентификаторам сборщика и чанка • Сборщики одного пользователи могут попадать в разные шарды • Запрос “покажи мне все сборщики конкретного пользователя” вынужден выполняться с RUN ON ALL • Начинали с 32 (!) логических шардов • Запрос оказался весьма частым • Наедались соединениями
  23. 23. 24 RUN ON ALL • Не стоит использовать для частых запросов • Сократили количество шардов с 32 до 4 • Закэшировали результаты этого запроса в приложении
  24. 24. 25 Нам не хватает: • Интерфейс ожиданий и трассировка сессии • Возможность отдать под shared_buffers всю память и включить O_DIRECT • Нормальное партиционирование • Полусинхронная репликация • Параллелизм: – Восстановление реплики – pg_basebackup – Другие операции • Advisory locks с таймаутами
  25. 25. Итоги
  26. 26. 27 • 2+ ТБ данных (15+ млрд. строк) • 40000+ rps • ~ -1 oracle • ~ 6 месяцев 0,5 человека • Хорошее начало светлого пути: – Много полезного опыта для DBA – Много переиспользуемого кода для разработчиков – Положительное мнение о PostgreSQL у всех :) Итоги
  27. 27. Владимир Бородин Системный администратор +7 495 739-70-00 (доб. 7255) d0uble@yandex-team.ru 119021, Москва, ул. Льва Толстого, 18Б Спасибо

×