Привет, Habr! На связи эксперты команды сервиса WatchDog — Дмитрий Коновалов и Геннадий Переломов.

В ВТБ, у нашего основного заказчика, мы развиваем сервисы автоматизации сопровождения баз данных. Одной из ключевых СУБД в инфраструктуре является PostgreSQL. Поддержка её в актуальном состоянии требует периодических мажорных обновлений, которые остаются одной из самых трудоёмких задач для DBA, особенно в ночные или выходные технологические окна.

В этой статье мы расскажем, как разработали внутренний сервис, позволяющий администраторам прикладных систем запускать мажорное обновление PostgreSQL в один клик и без участия DBA.

Зачем автоматизировать мажорные обновления PostgreSQL

Жизненный цикл мажорной версии PostgreSQL — 5 лет. Чтобы оставаться в зоне официальной поддержки, получать новые возможности и улучшения, и при этом соответствовать внутренним нормативным документам (ВНД), необходимо регулярно обновлять инсталляции. На момент старта проекта в ВТБ было несколько тысяч экземпляров PostgreSQL, и ручное обновление каждого из них было бы затратным и рискованным.

Постановка задачи

В мае 2023 года перед нами поставили задачу:

Создать сервис (условно — «кнопку»), который позволит администраторам АБС выполнять мажорное обновление PostgreSQL без участия DBA.

Требования:

• Поддержка standalone и cluster конфигураций.

• Надёжность — на входе и выходе должен быть рабочий экземпляр PostgreSQL.

• Минимизация человеческого фактора.

• Поддержка расширений pg_stat_statements и pgaudit.

• Обязательное выполнение резервного копирования.

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

Анализ и подготовка

Мы изучили:

• статистику используемых версий PostgreSQL (от 11 до начинающейся 15),

• типовые расширения и модули,

• текущие процессы обновления,

• особенности конфигураций (Patroni, standalone),

• ограничения по времени обновлений (ночное окно).

В результате мы сузили фокус:

• поддержка обновлений до версий 14 и 15,

• анализ расширений и автоматическая проверка их наличия,

• обязательные предварительные проверки, чтобы гарантировать запуск PostgreSQL после обновления.

Реализация: архитектура «кнопки»

Сценарий был разбит на две части:

• Frontend: веб-интерфейс с выбором сервера и мажорной версии;

• Backend: масштабный Ansible Playbook (более 3000 строк и ~100 шагов).

Форма пользователя:

• Выбор сервера из доступных.

• Выбор версии обновления (14 или 15).

• Отображение ограничений сценария.

• Чекбокс «Я понимаю, что делаю» — без него запуск невозможен.

Структура playbook

Шесть основных блоков + блоки отката:

1.     Предварительные проверки:

• Доступность экземпляра,

• Конфигурация,

• Наличие расширений,

• Соответствие чеклисту.

2.     Установка новой версии PostgreSQL.

3.     Подготовка к pg_upgrade:

• Dump-проверка,

• Тестовое выполнение pg_upgrade.

4.     Запуск pg_upgrade.

5.     Бэкап:

• Для cluster — бэкапом является сама реплика, которую сценарий не трогает пока успешно не обновим лидер,

• Для standalone — до выполнения pg_upgrade.

6.     Финальные проверки и правки конфигурации.

Механизмы отката

Механизмы отката предусмотрены для всех этапов до и после неуспешного выполнения pg_upgrade. В случае ошибки сценарий восстанавливает PostgreSQL в изначальное рабочее состояние.

Дополнительно:

• Обновление Patroni до целевой версии (если требуется).

• Асинхронное выполнение ресурсоёмких операций: pg_upgrade, vacuumdb, pg_dump, бэкап.

Тестирование

Мы провели тестирование по всем возможным сценариям:

• Все поддерживаемые мажорные версии;

• Разные объёмы $PGDATA, LO, количество таблиц;

• Все комбинации включённых расширений;

• Все блоки отката.

Результаты показали надежную работу сценария.

Результаты эксплуатации

На момент публикации сценарий находится в боевой эксплуатации более полутора лет, за это время проведено свыше 1000 успешных обновлений PostgreSQL, а также добавлена поддержка обновления до версии 16.

Статистика работы сценария в ПРОД среде:

Заключение

Ключом к успешному внедрению стало соблюдение чеклистов и подготовка экземпляров — спасибо команде сопровождения PostgreSQL и сервису контроля инфраструктуры WatchDog.

Мы продолжаем развивать сценарий, и с нетерпением ждём появления в Банке версии PostgreSQL 17, чтобы добавить её поддержку в нашу «кнопку».

Что дальше

Если у вас есть опыт автоматизации обновлений PostgreSQL — поделитесь в комментариях. Какие подходы вы используете? Как решаете проблему rollback? Насколько глубоко интегрируете с CI/CD?

Мы открыты к диалогу.