PostgreSQL: обходим подводные камни при миграции02.08.2023 14:01

Привет! Меня зовут Антон Казачков, я специалист вендорской поддержки СУБД Platform V Pangolin. Это реляционная СУБД уровня enterprise, которая разработана в СберТехе на основе PostgreSQL и доработана до корпоративного уровня надёжности и производительности. Сегодня Pangolin — целевая СУБД Сбера, основа для миграции всех существующих приложений и разработки новых.

Расскажу о ситуациях, с которыми сталкиваются команды на последних этапах миграции СУБД и в начале производственного цикла. На Хабре часто обсуждаются нюансы переезда СУБД из разных проприетарных версий на PostgreSQL. А вот информации о том, как вводить базы в эксплуатацию и выявлять производственные «болячки», на мой взгляд, не так много.

Миграция на финишной прямой — что может пойти не так?

Как правило, миграция включает в себя выбор и подготовку экземпляра или кластера, перенос данных, переписывание кода, несколько этапов функционального и нагрузочного тестирования. Но при тестировании часто обнаруживается, что БД работает не совсем так, как планировалось. Не работают или отсутствуют индексы, процессы конкурируют за блокировки, мониторинг показывает маленький TPS или непонятные пики в использовании ресурсов — и так далее, вплоть до падения сервиса.

Предположим, миграция данных состоялась, система запущена в рабочем профиле нагрузки, но что-то идёт не так. Как понять, что именно? С одной стороны, есть мониторинг, по которому можно собрать анамнез: время и симптомы проблемы. С другой стороны, в системах мониторинга, как правило, отсутствуют запросы к БД и затраты на их исполнение. Поэтому одного мониторинга для решения проблемы недостаточно.

Какие варианты решения существуют:

оперативный анализ статистических представлений через, например, pgcenter Алексея Лесовского;
включение auto_explain и анализ логов;
инструментарий ОС: perf record, atop, strace, ltrace и пр.

Как видите, большинство инструментов либо представляют собой средства оперативного вмешательства, либо требуют специальных знаний. Исключением являются логи БД, но в них может находиться чувствительная информация. Кроме того, включение логирования запросов — не бесплатная операция, она приводит к перерасходу места в ОС и некоторым затратам СУБД на формирование лога. А анализ статистических представлений и вовсе зависит от работы СУБД, не имеет временных отметок и не применим для postmortem.

Решение: создаём performance insight и pg_profile, инструменты для выявления проблем производительности

До последнего времени анализ проблем производительности у нас основывался на изучении логов СУБД, применении explain к подозрительным запросам и подборе параметров для explain, при которых проявлялась проблема. Трудности начинались при вычислении затрат на исполнение запроса и конкурентных блокировок.

В итоге мы пришли к выводу, что текущего инструментария нам не хватает, и нужно написать что-то своё по мотивам проприетарных решений. Какие задачи должен решать инструмент:

Семплировать статистические метрики из pg_stat_activity и pg_locks c заданной периодичностью по всем БД экземпляра.
Сохранять определённое количество семплов в памяти, периодически сбрасывая их на диск. Глубина хранения на диске должна быть ограничена.
При завершении работы постмастера, в том числе аварийной, сбрасывать несохранённые данные на диск.
При старте постмастера считывать определённое количество последних семплов в память.

Что ещё было важно:

Прозрачная работа для СУБД с минимальным влиянием на систему.
Способность работать на всех нодах кластера, включая ведомые при физической репликации.
Работа инструмента не должна менять профиль нагрузки БД (включая блокировки).
Независимость от сетевой доступности.
Пользовательские интерфейсы — SQL (пользователи могут не иметь доступа к консоли ОС).