28

2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Embed Size (px)

DESCRIPTION

Опыт миграции с Oracle на PostgreSQL в проекте Яндекс.Почта

Citation preview

Page 1: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)
Page 2: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Владимир БородинСистемный администратор

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

Page 3: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

3

Коротко

• Про сборщики

• Масштабирование

• Отказоустойчивость

• Мониторинг

• Проблемы

• Итоги

Page 4: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Про сборщики

Page 5: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

5 Что это?

Page 6: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

6

Как это было?

• Все метаданные в oracle

• Шардирование по пользователям на стороне другого сервиса

• Все запросы только в мастер

• Сборщик работает с чанком из 1000 заданий

• Чанки распределяются между сборщиками с помощью хранимой логики в базе

Page 7: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

7

Почему сборщики?

• Легко отчуждаемы– Нет взаимосвязей с другими данными в oracle

• Наименее критичный по SLA сервис– Имеет право не работать единицы минут

• Ощутимые объём данных и нагрузка– 2+ ТБ данных и ~40k rps

Page 8: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Масштабирование

Page 9: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

9 Общая схема

Page 10: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

10

PL\Proxy

• Положительный опыт у ребят из Skype

• Нет необходимости в костылях для шардирования в другом сервисе

• Больший контроль в руках DBA

• Более простой вариант смены СУБД для приложения– Шардирование и отказоустойчивость– Хранимая логика в базе

Page 11: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

11

• Шардирование по диапазонам ключей

• Ключи из sequence'ов, которые на конечных базах разные

• При добавлении нового шарда мастер конечной базы: – через FDW заносит информацию на pgmeta

– меняет sequence'ы

• Эта информация доезжает до всех plproxy-машин

PL\Proxy

Page 12: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Отказоустойчивость

• pgcheck

• pgswitch

• pgsync

Page 13: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

13

pgcheck

• Назначает приоритеты машинам конечных баз в зависимости от:– Живости машины,– Её роли (мастер/реплика),– В случае реплик:

• Удалённости (ЦОД),• (А)синхронности,• Нагрузки,• TODO: отставания.

• Это меняет поведение функции plproxy.get_cluster_partitions

Page 14: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

14 Деградация в read-only в случае потери мастера

Page 15: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

15

pgswitch

• Скрипт для планового переключения мастера, запускаемый на реплике

• Проверяет всё, что можно и нужно, на старом и новых мастерах

• Переключает мастера и все реплики на нового мастера

• В любой непонятной ситуации паникует

Page 16: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

16

pgsync

• Живёт на конечных базах• Меняет репликацию с синхронной на

асинхронную и обратно• Автоматическое переключение мастера без

потери данных• Пока только в тестинге

Page 17: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Мониторинг

Page 18: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

18

pg-active-sessions | Количество активных сессийpg-connections | Количество свободных соединенийpg-log-errors | Количество ошибок в журнале(-ах) за последнюю минутуpg-mounted-nfs | Смонтированность nfs-каталоговpg-ping | SELECT 1 в PostgreSQLpg-replication-alive | Количество живых репликpg-replication-lag | Лаг реплики в байтахpg-vacuum | Время последнего vacuum/analyze для всех таблицpg-xlog-files | Количество незаархивированных xlog'овpgbouncer | TCP chat на порт 6432 на каждой машинеyrpop-errors | Количество ошибок ymod_pq в yrpop.log

Проверки

Page 19: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

19

Графики

• Начинали с pg_stats_reporter• Сейчас ищем ему замену• И почти всё рисуем в graphite

Page 20: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

20 Пример дашборда

Page 21: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Проблемы

Page 22: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

22

По первости

• По привычке отрезали много памяти под shared_buffers

• Много оптимизировали дисковую подсистему– raid'ы с файловыми системами– page cache– Checkpoints/autovacuum/bgwriter

Page 23: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

23

RUN ON ALL

• Шардирование сделали по идентификаторам сборщика и чанка

• Сборщики одного пользователи могут попадать в разные шарды

• Запрос “покажи мне все сборщики конкретного пользователя” вынужден выполняться с RUN ON ALL

• Начинали с 32 (!) логических шардов

• Запрос оказался весьма частым

• Наедались соединениями

Page 24: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

24

RUN ON ALL

• Не стоит использовать для частых запросов

• Сократили количество шардов с 32 до 4

• Закэшировали результаты этого запроса в приложении

Page 25: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

25

Нам не хватает:

• Интерфейс ожиданий и трассировка сессии

• Возможность отдать под shared_buffers всю память и включить O_DIRECT

• Нормальное партиционирование

• Полусинхронная репликация

• Параллелизм:– Восстановление реплики– pg_basebackup– Другие операции

• Advisory locks с таймаутами

Page 26: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Итоги

Page 27: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

27

• 2+ ТБ данных (15+ млрд. строк)

• 40000+ rps

• ~ -1 oracle

• ~ 6 месяцев 0,5 человека

• Хорошее начало светлого пути:– Много полезного опыта для DBA– Много переиспользуемого кода для разработчиков

– Положительное мнение о PostgreSQL у всех :)

Итоги

Page 28: 2014.09.24 история небольшого успеха с PostgreSQL (Yandex)

Владимир Бородин

Системный администратор

+7 495 739-70-00 (доб. 7255)

[email protected]

119021, Москва, ул. Льва Толстого, 18Б

Спасибо