Как бы ты обновлял версию PostgreSQL

Стратегия обновления версии PostgreSQL

Как Senior DevOps Engineer с более чем 10-летним опытом, я выстраиваю процесс обновления PostgreSQL по принципу "минимизация рисков при максимальной доступности". Обновление СУБД — одна из самых критичных операций, поэтому подход должен быть методичным и осторожным.

Основные методы обновления

Существует три основных подхода, выбор которых зависит от требований к доступности, объема данных и допустимого времени простоя:

1. Минорные обновления (patch updates) — простейший случай, обычно требует только перезагрузки PostgreSQL
2. Мажорные обновления с дампом/восстановлением — универсальный, но требует продолжительного простоя
3. Мажорные обновления с логической репликацией — минимальный простой, но более сложная настройка

Поэтапный план обновления

Этап 1: Подготовка (Pre-flight checks)

Перед любым обновлением выполняю:

# Проверяем текущую версию и конфигурацию
psql -c "SELECT version();"
psql -c "SHOW data_directory;"

# Анализируем размер БД и критичные таблицы
psql -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) 
         FROM pg_database ORDER BY pg_database_size(datname) DESC;"

# Проверяем расширения (extensions) и их совместимость
psql -c "SELECT extname, extversion FROM pg_extension;"

# Делаем полный бэкап (независимо от стратегии обновления)
pg_dumpall -U postgres -f /backups/postgres_full_backup_$(date +%Y%m%d).sql

Создаю чек-лист совместимости:

• Проверяю устаревшие функции через pg_upgrade --check
• Анализирую изменения в синтаксисе между версиями
• Тестирую совместимость всех подключенных приложений

Этап 2: Выбор стратегии обновления

Для production-окружений с высокими требованиями к доступности предпочитаю метод логической репликации:

-- На исходном сервере (source, старая версия)
ALTER SYSTEM SET wal_level = logical;
SELECT pg_reload_conf();

-- Создаем публикацию для всех таблиц
CREATE PUBLICATION pg_upgrade_pub FOR ALL TABLES;

-- На целевом сервере (target, новая версия PostgreSQL)
-- Создаем подписку
CREATE SUBSCRIPTION pg_upgrade_sub 
CONNECTION 'host=source_host port=5432 dbname=mydb user=repl'
PUBLICATION pg_upgrade_pub;

Для систем с допустимым простоем (оконные периоды) использую pg_upgrade с link-режимом:

# Останавливаем PostgreSQL
sudo systemctl stop postgresql-13

# Запускаем обновление с сохранением кластера
sudo -u postgres /usr/pgsql-14/bin/pg_upgrade \
  --old-bindir=/usr/pgsql-13/bin \
  --new-bindir=/usr/pgsql-14/bin \
  --old-datadir=/var/lib/pgsql/13/data \
  --new-datadir=/var/lib/pgsql/14/data \
  --link \
  --check

# Если проверка прошла успешно, запускаем настоящее обновление
sudo -u postgres /usr/pgsql-14/bin/pg_upgrade \
  --old-bindir=/usr/pgsql-13/bin \
  --new-bindir=/usr/pgsql-14/bin \
  --old-datadir=/var/lib/pgsql/13/data \
  --new-datadir=/var/lib/pgsql/14/data \
  --link

Этап 3: Тестирование в staging-окружении

Перед production-внедрением обязательно:

1. Разворачиваю полную копию production-окружения
2. Выполняю тестовое обновление по выбранной стратегии
3. Провожу нагрузочное тестирование обновленной БД
4. Проверяю работу всех приложений и отчетов
5. Замеряю производительность критичных запросов

Этап 4: Production-внедрение с откатом

Для production использую синий-зеленый подход:

# Сценарий для быстрого отката при проблемах
#!/bin/bash
# Часть процедуры обновления с проверками
NEW_VERSION="14"
OLD_VERSION="13"

# После обновления выполняю серию проверок
CHECK_QUERIES=(
  "SELECT 1"
  "SELECT COUNT(*) FROM important_table"
  "EXPLAIN ANALYZE SELECT * FROM critical_view LIMIT 1"
)

for query in "${CHECK_QUERIES[@]}"; do
  if ! psql -U postgres -c "$query" > /dev/null 2>&1; then
    echo "Check failed: $query"
    echo "Initiating rollback to PostgreSQL $OLD_VERSION"
    # Процедура отката
    systemctl stop postgresql-$NEW_VERSION
    systemctl start postgresql-$OLD_VERSION
    exit 1
  fi
done

Критические аспекты для production

1. Тайминги и мониторинг:

   • Обновление планирую на время наименьшей нагрузки
   • Настраиваю расширенный мониторинг (Prometheus + Grafana) до, во время и после обновления
   • Устанавливаю четкие метрики успешности (латентность, throughput, ошибки приложений)

2. Работа с расширениями:

   # Обновление расширений после мажорного обновления
   psql -c "ALTER EXTENSION postgis UPDATE;"
   psql -c "ALTER EXTENSION pgcrypto UPDATE;"
   

3. Коммуникация и документация:

   • Создаю runbook для команды поддержки
   • Устанавливаю понятные точки контроля
   • Готовлю откатные процедуры для каждого этапа

Пост-обновляционные задачи

После успешного обновления:

• Запускаю ANALYZE для обновления статистики
• Проверяю и перестраиваю индексы при необходимости
• Мониторю производительность в течение недели
• Обновляю документацию инфраструктуры
• Удаляю резервные копии старой версии через agreed retention period

Ключевой принцип: никогда не обновляю production без предварительного тестирования в изолированном окружении, максимально приближенном к боевому. Для критически важных систем всегда имею подготовленный и протестированный план отката, который можно выполнить в течение SLA восстановления.