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.
Loading in …3
×
18 of 28

История небольшого успеха с PostgreSQL – Владимир Бородин

1

Share

Download to read offline

В докладе речь пойдёт о том, как в Яндекс.Почту для хранения метаданных сборщиков внедрили PostgreSQL. Владимир расскажет, зачем и почему это сделали и каким образом решили масштабироваться. А также о репликации и средствах обеспечения отказоустойчивости, о возникших проблемах и способах их решения.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

История небольшого успеха с 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 PLProxy • Шардирование по диапазонам ключей • Ключи из sequence'ов, которые на конечных базах разные • При добавлении нового шарда мастер конечной базы: – через FDW заносит информацию на pgmeta – меняет sequence'ы • Эта информация доезжает до всех 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. Владимир Бородин Системный администратор d0uble@yandex-team.ru +7 495 739-70-00 (доб. 7255) 119021, Москва, ул. Льва Толстого, 18Б Спасибо

×