Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
История 
небольшого успеха 
с PostgreSQL 
Владимир Бородин 
Системный администратор
3 
Коротко 
• Про сборщики 
• Масштабирование 
• Отказоустойчивость 
• Мониторинг 
• Проблемы 
• Итоги
Про сборщики
5 Что это?
6 
Как это было? 
• Все метаданные в oracle 
• Шардирование по пользователям на 
стороне другого сервиса 
• Все запросы то...
7 
Почему сборщики? 
• Легко отчуждаемы 
– Нет взаимосвязей с другими данными в 
oracle 
• Наименее критичный по SLA серви...
Масштабирование
9 Общая схема
10 
PLProxy 
• Положительный опыт у ребят из Skype 
• Нет необходимости в костылях для 
шардирования в другом сервисе 
• Б...
11 
PLProxy 
• Шардирование по диапазонам ключей 
• Ключи из sequence'ов, которые на конечных 
базах разные 
• При добавле...
Отказоустойчивость 
• pgcheck 
• pgswitch 
• pgsync
13 
pgcheck 
• Назначает приоритеты машинам конечных 
баз в зависимости от: 
– Живости машины, 
– Её роли (мастер/реплика)...
14 Деградация в read-only в случае потери мастера
15 
pgswitch 
• Скрипт для планового переключения 
мастера, запускаемый на реплике 
• Проверяет всё, что можно и нужно, на...
16 
pgsync 
• Живёт на конечных базах 
• Меняет репликацию с синхронной на 
асинхронную и обратно 
• Автоматическое перекл...
Мониторинг
18 
Проверки 
pg-active-sessions | Количество активных сессий 
pg-connections | Количество свободных соединений 
pg-log-er...
19 
Графики 
• Начинали с pg_stats_reporter 
• Сейчас ищем ему замену 
• И почти всё рисуем в graphite
20 Пример дашборда
Проблемы
22 
По первости 
• По привычке отрезали много памяти под 
shared_buffers 
• Много оптимизировали дисковую 
подсистему 
– r...
23 
RUN ON ALL 
• Шардирование сделали по 
идентификаторам сборщика и чанка 
• Сборщики одного пользователи могут 
попадат...
24 
RUN ON ALL 
• Не стоит использовать для частых запросов 
• Сократили количество шардов с 32 до 4 
• Закэшировали резул...
25 
Нам не хватает: 
• Интерфейс ожиданий и трассировка сессии 
• Возможность отдать под shared_buffers всю 
память и вклю...
Итоги
27 
Итоги 
• 2+ ТБ данных (15+ млрд. строк) 
• 40000+ rps 
• ~ -1 oracle 
• ~ 6 месяцев 0,5 человека 
• Хорошее начало све...
Владимир Бородин 
Системный администратор 
d0uble@yandex-team.ru 
+7 495 739-70-00 (доб. 7255) 
119021, Москва, ул. Льва 
...
История небольшого успеха с PostgreSQL – Владимир Бородин
Próximo SlideShare
Cargando en…5
×

de

История небольшого успеха с PostgreSQL – Владимир Бородин Slide 1 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 2 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 3 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 4 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 5 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 6 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 7 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 8 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 9 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 10 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 11 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 12 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 13 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 14 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 15 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 16 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 17 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 18 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 19 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 20 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 21 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 22 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 23 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 24 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 25 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 26 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 27 История небольшого успеха с PostgreSQL – Владимир Бородин Slide 28
Próximo SlideShare
"Развитие ветки PHP-7"
Siguiente
Descargar para leer sin conexión y ver en pantalla completa.

1 recomendación

Compartir

Descargar para leer sin conexión

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

Descargar para leer sin conexión

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

Libros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

Audiolibros relacionados

Gratis con una prueba de 30 días de Scribd

Ver todo

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

    Oct. 1, 2014

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

Vistas

Total de vistas

2.507

En Slideshare

0

De embebidos

0

Número de embebidos

566

Acciones

Descargas

21

Compartidos

0

Comentarios

0

Me gusta

1

×