Миграция баз данных PostgreSQL при обновлении на Ubuntu 24.04

Содержание

Перенос базы данных — одна из сложнейших задач при обновлении инфраструктуры. Статья посвящена миграции БД PostgreSQL при обновлении системы до Ubuntu 24.04 для вашего сервера (VPS): подготовка к миграции, процесс переноса данных и пост-миграционные задачи.

Введение

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

Репликация позволяет минимизировать простой, но требует более сложной настройки. Выбор оптимальной стратегии зависит от множества факторов: объёма данных, допустимого времени простоя, пропускной способности сети и архитектурных особенностей конкретного приложения.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Подготовка к миграции

Первый шаг успешного переноса базы данных — грамотная подготовка. Она включает анализ текущего состояния системы, проверку совместимости версий и выявление потенциальных рисков. Без этих шагов легко упустить критичные детали, что в дальнейшем может привести к ошибкам и простоям.

Аудит текущего состояния

Перед началом любых миграционных работ нужно провести всесторонний аудит существующей базы данных. Определите точный объём данных:

SELECT pg_database_size('your_database_name');

Следующий этап — полная инвентаризация объектов базы данных:

расширения PostgreSQL:

SELECT * FROM pg_extension;

пользовательские функции и процедуры,
триггеры и правила,
пользовательские типы данных и операторы,
настройки аутентификации и права доступа.

Проверьте совместимость версий СУБД:

определите текущую версию PostgreSQL:

SELECT version();

изучите официальную документацию по обновлению для целевых версий,
проверьте устаревшие функции и изменившийся синтаксис.

Стратегии миграции

Метод дампа и восстановления (Dump/Restore). Не требует сложных настроек и обеспечивает целостность данных, но предполагает значительный простой системы — от нескольких часов до суток в зависимости от объёма данных — и требует дополнительного дискового пространства (примерно в два раза больше размера базы данных). Рекомендуется для баз объемом до 100 ГБ, где возможен продолжительный простой.

Физическая репликация. Обеспечивает минимальное время простоя за счёт непрерывной потоковой передачи WAL-записей между старым и новым сервером. Этот метод позволяет проводить тестирование производительности на реплике до момента переключения. К недостаткам относятся требование идентичной архитектуры и версии PostgreSQL (в рамках major-версии) и необходимость мониторинга задержки репликации. Метод подойдёт для крупных баз данных (от 500 ГБ), где критически важен минимальный простой.

pg_upgrade обеспечивают максимальную скорость миграции за счёт прямого копирования файлов данных и требуют минимального дополнительного пространства на диске. Однако метод применяется только для миграции на одном сервере и только между совместимыми major-версиями (например, с 14-й на 16-ю версию PostgreSQL), требует идентичной архитектуры процессора и не поддерживает изменение параметров кластеризации.

Проверка на тестовом стенде

Создайте тестовое окружение и протестируйте переход не пропуская ни одного этапа:

Создание полной резервной копии старой базы данных.
Клонирование продакшен-сервера с помощью инструментов виртуализации.
Точное копирование конфигураций и данных.
Проведение полного цикла тестовой миграции.
Нагрузочное тестирование после миграции.
Проверка всех бизнес-процессов и отчётов.
Отработка отката.

Подготовка новой среды

Установите современную версию PostgreSQL на сервере с Ubuntu 24.04, настройте производительность, учитывая характеристики оборудования.

Если вы выбрали метод репликации, то выполните следующие шаги.

На сервере-источнике — убедитесь, что в postgresql.conf включена репликация:

wal_level = replica
max_wal_senders = 10
wal_keep_size = 1024

Создайте слот физической репликации (в примере — с именем migration_slot):

sudo -u postgres psql -c "SELECT pg_create_physical_replication_slot('migration_slot');"

Создайте пользователя для репликации:

CREATE USER replica_user WITH REPLICATION ENCRYPTED PASSWORD 'secure_password';

Настройте аутентификацию в pg_hba.conf:

host replication replica_user <IP_НОВОГО_СЕРВЕРА>/32 scram-sha-256

Перезагрузите сервер:

sudo systemctl reload postgresql

На новом сервере остановите новый кластер PostgreSQL:

sudo systemctl stop postgresql@16-main

Полностью удалите содержимое каталога данных:

sudo -u postgres rm -rf /var/lib/postgresql/16/main/

После выполнения всех настроек обязательно проверьте корректность конфигурации PostgreSQL:

sudo systemctl restart postgresql
sudo -u postgres psql -c "SELECT * FROM pg_replication_slots;"

Дополнительно можно настроить мониторинг репликации и автоматическое оповещение о проблемах через встроенные механизмы СУБД или внешние системы мониторинга.

Процесс миграции

Когда подготовка завершена и новая среда развернута, можно переходить к основному этапу — переносу данных. На этом шаге важно выбрать подходящий инструмент и метод миграции в зависимости от объёма базы, доступного времени простоя и требований к инфраструктуре. PostgreSQL поддерживает несколько сценариев, каждый из которых имеет свои особенности.

Миграция с помощью дампа

Создание дампа:

pg_dump -Fc --verbose --file=prod_db.dump DB_NAME

Перенос дампа на новый сервер с проверкой целостности.

Копирование с прогрессом и проверкой checksum:

rsync -avz --progress --checksum prod_db.dump user@new-server:/path/to/backup/

Проверка целостности после передачи:

sha256sum prod_db.dump

Восстановление на новом сервере:

pg_restore --jobs=4 --verbose --dbname=NEW_DB_NAME prod_db.dump

Миграция через репликацию

Инициализация реплики:

sudo -u postgres pg_basebackup -h <IP_СТАРОГО_СЕРВЕРА> -p 5432 -U replica_user -D /var/lib/postgresql/16/main/ -Fp -Xs -P -R -S migration_slot

Ключ -R автоматически создаст файл standby.signal и добавит настройки подключения в postgresql.auto.conf.

Запустите сервер:

sudo systemctl start postgresql@16-main

Мониторинг процесса.

На сервере-источнике:

SELECT pg_current_wal_lsn(), pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) 

FROM pg_stat_replication;

Мониторинг на реплике:

SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();

Переключение трафика.

Остановите запись на старом сервере:

запретите новые подключения к базе данных:

REVOKE CONNECT ON DATABASE your_database FROM PUBLIC;

завершите все активные соединения (используйте с осторожностью в продакшене):

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid();

Проверьте, что реплика догнала источник:

SELECT pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn());

Перенаправьте входящий трафик ваших приложений со старой базы данных на новую через DNS или балансировщик нагрузки и переведите реплику в режим primary:

SELECT pg_promote();

Использование pg_upgrade

К моменту перехода на сервере уже должны быть установлена и настроена новая версия PostgreSQL. Предварительная проверка (в примере миграция данных с 14-й на 16-ю версию):

pg_upgrade --check \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/16/bin \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/16/main

Если проверка прошла успешно, выполните миграцию:

pg_upgrade --link \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/16/bin \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/16/main

Запустите новый кластер:

sudo systemctl start postgresql@16-main

После завершения любого из сценариев обязательно выполните:

анализ и обновление статистики:

vacuumdb --analyze-in-stages --all

проверка целостности данных:

pg_amcheck your_database_name

Пост-миграционные задачи

Завершение переноса не означает конец работы. После успешной миграции необходимо убедиться, что данные сохранили целостность, система работает стабильно, а производительность соответствует ожиданиям. Эти проверки помогают выявить скрытые проблемы до того, как они проявятся в продакшене.

Валидация данных

После миграции проведите тщательную проверку целостности данных PostgreSQL.

Проверка количества записей в основных таблицах:

SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

Сравнение контрольных сумм таблиц:

SELECT md5(array_agg(t ORDER BY id)::text)
FROM (
    SELECT id, md5((t.*)::text)
    FROM important_table t
    ORDER BY id
) s;

Проверка целостности страниц данных:

pg_checksums --enable --progress

Тестирование производительности

Запустите нагрузочные тесты для сравнения производительности до и после миграции:

pgbench -i -s 100 your_database  # инициализация тестовой БД
pgbench -c 50 -j 4 -T 300 your_database  # запуск теста

Проанализируйте ключевые метрики:

TPS (количество транзакций в секунду),
задержки (латентность), 95-й и 99-й процентили,
утилизация ресурсов CPU, RAM, I/O.

Обновление расширений и зависимостей

Переустановите и обновите расширения для совместимости с новой версией PostgreSQL:

sudo apt install postgresql-16-postgis-3 postgresql-16-timescaledb

Восстановление расширений в БД:

psql -d your_database -c "ALTER EXTENSION postgis UPDATE;"
psql -d your_database -c "ALTER EXTENSION timescaledb UPDATE;"

Проверка версий расширений:

SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE installed_version IS NOT NULL;

После завершения всех пост-миграционных задач проведите финальное нагрузочное тестирование в пиковые часы для подтверждения стабильной работы системы под реальной нагрузкой.

Заключение

Миграция PostgreSQL на Ubuntu 24.04 требует внимательной подготовки, выбора подходящей стратегии и обязательного тестирования на стенде. Ошибки на этом этапе могут обернуться потерей данных и простоями, поэтому критически важно учитывать объём БД, допустимое время недоступности и совместимость версий.

Использование дампа подходит для небольших систем, репликация позволяет минимизировать простой, а pg_upgrade обеспечивает наибольшую скорость при соблюдении ограничений. Завершающим этапом всегда остаются валидация, нагрузочные тесты и обновление расширений.

Только комплексный подход гарантирует успешный переход на новую версию Ubuntu и стабильную работу PostgreSQL на вашем VPS без риска для бизнеса.

Читайте в блоге: