Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

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

  • Identifiez-vous pour voir les commentaires

  • Soyez le premier à aimer ceci

История небольшого успеха с 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Б Спасибо

×