Миграция PostgreSQL с минимальным простоем

Введение

PostgreSQL — надёжный сервер баз данных. При больших объёмах данных традиционный pg_dump может занимать много времени. В этом руководстве описан подход для миграции всего сервера с минимальным временем простоя с помощью PITR (Point in Time Recovery) и архивирования WAL (Write-Ahead Logging).

Важно: в примерах используются PostgreSQL 8.3 и Debian/Ubuntu-подобные дистрибутивы. Версии PostgreSQL на источнике и назначении должны совпадать — нельзя мигрировать с 8.3 на 8.4 этим методом.

Внимание: каталог данных на сервере назначения будет перезаписан и потерян. Сделайте резервные копии перед началом.

Основная идея (одним предложением)

PITR включает постоянную архивацию WAL-файлов на источник; мы копируем начальную снимок (base backup) и все WAL-файлы на целевой хост, а затем «пробуждаем» целевой сервер с помощью триггерного файла, чтобы он завершил восстановление и продолжил работу как основной.

Предпосылки

Два сервера с PostgreSQL 8.3 (источник и назначение). Версии должны быть одинаковыми.
root/ssh-доступ для синхронизации данных (rsync).
Достаточно места на обоих хостах для базы данных и архива WAL.
Базовые навыки работы с Linux и psql.

Подготовка

Прочитайте весь документ перед выполнением команд. Если вы не понимаете команду — не выполняйте её. Неправильные действия могут уничтожить базу данных. Всегда имейте рабочую резервную копию.

Важно: с момента создания триггерного файла целевой сервер перестанет принимать новые данные с источника. Планируйте окно переключения.

Настройка исходного сервера (source)

Убедитесь, что сервер назначения НЕ запущен.

Создайте каталог архива WAL на исходном сервере и установите владельца postgres:

mkdir /archive; chown postgres.postgres /archive;

Отредактируйте /etc/postgresql/8.3/main/postgresql.conf и включите архивацию WAL. Пример правок:

# vim /etc/postgresql/8.3/main/postgresql.conf

Добавьте строки:

archive_mode = on
archive_command = 'cp -i %p /archive%f'

Примечание: по умолчанию WAL-файл имеет размер 16 МБ; при большой активности БД архив может быстро расти.

Переведите PostgreSQL в режим «backup» для создания базового снимка:

# sudo /etc/init.d/postgresql-8.3 reload
# sudo su postgres
# psql
postgres=# SELECT pg_start_backup('backup');
postgres=# \q

Если после SELECT pg_start_backup возникла ошибка — устраните её и повторите.

Скопируйте каталог данных на сервер назначения. Для надёжности используем rsync:

rsync --progress -azv --delete /var/lib/postgresql/8.3/main/ root@:/var/lib/postgresql/8.3/main

Завершите режим backup на исходном сервере:

# sudo su postgres
# psql
postgres=# SELECT pg_stop_backup();
postgres=# \q

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

Настройка целевого сервера (destination)

На целевом сервере подготовьте каталог архива и настройте восстановление.

Создайте каталог архива и установите владельца:

# sudo mkdir /archive; sudo chown postgres.postgres /archive;

Установите дополнительные утилиты, если нужно:

# sudo apt-get install postgresql-contrib-8.3

Создайте файл восстановления /var/lib/postgresql/8.3/main/recovery.conf и вставьте строку restore_command. Пример:

# sudo vim /var/lib/postgresql/8.3/main/recovery.conf

Добавьте:

restore_command = '/usr/lib/postgresql/8.3/bin/pg_standby -l -d -s 2 -t /tmp/pgsql.trigger /archive %f %p %r 2>>standby.log'

Пояснение: pg_standby удобен для поэтапного восстановления WAL; он будет извлекать WAL-файлы из /archive и применять их до создания триггерного файла.

Синхронизируйте каталог /archive с источником (можно с целевого хоста):

# sudo rsync --progress -azv --delete root@:/archive /archive

Запустите PostgreSQL на целевом сервере:

# sudo /etc/init.d/postgresql-8.3 start

Целевой сервер теперь в состоянии восстановления и будет применять WAL-файлы по мере их наличия.

Окончательное переключение (минимальное время простоя)

Когда вы готовы переключиться в рабочее состояние на целевом сервере:

Повторно синхронизируйте /archive, чтобы захватить последние WAL-файлы:

# sudo rsync --progress -azv --delete root@:/archive /archive

Создайте trigger-файл, чтобы целевой сервер завершил восстановление и стал принимать записи:

# sudo su -c 'touch /tmp/pgsql.trigger' postgres

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

Проверка и постработы

Проверьте логи на целевом сервере (/var/log/postgresql и standby.log).
Выполните тестовые запросы и контрольные суммы по критическим таблицам.
Обновите DNS или прокси/балансировщик для направления трафика на новый сервер.

Откат и восстановление старого состояния

Если требуется откат:

Остановите PostgreSQL на целевом сервере:

# sudo /etc/init.d/postgresql-8.3 stop

Убедитесь, что оригинальный сервер всё ещё доступен и работает как прежде. Если оригинальный сервер остановлен, восстановите из его резервной копии.

Рекомендация: держите старый сервер в режиме «read-only» до завершения валидации нового.

Когда этот метод не подходит

Версии PostgreSQL различаются (нельзя мигрировать 8.3 → 8.4 этим способом).
У вас нет достаточного дискового пространства для base backup и архива WAL.
Требуется репликация в реальном времени без остановки записи — тогда лучше настройка потоковой репликации (streaming replication).

Альтернативные подходы

pg_dump/pg_restore: простая, но медленная для больших БД.
pg_basebackup или встроенная потоковая репликация: современный подход для непрерывной репликации.
Логическая репликация (например, pglogical) для более гибкой миграции между версиями.

Контрольный список ролей

DBA:

Подтвердить версии PostgreSQL на источнике и назначении
Настроить archive_mode и archive_command
Запустить/остановить pg_start_backup / pg_stop_backup

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

Обеспечить доступ SSH/rsync между серверами
Проверить свободное место для /var/lib/postgresql и /archive
Обновить DNS/балансировщик при переключении

DevOps:

Протестировать приложение на новом сервере
Настроить мониторинг и бэкапы на новом хосте

Критерии приёмки

Целевой сервер завершил recovery и отвечает на запросы.
Контрольные запросы возвращают ожидаемые результаты.
Латентность и нагрузка соответствуют SLA.
Резервный план отката проверен и готов.

Отладка и частые проблемы

Warnings в логах о невозможности найти WAL-файл: проверьте /archive и restore_command.
Если восстановление зависло — проверьте права доступа к /archive и наличие файлов.
Если после создания триггера база выдаёт ошибки — изучите postgresql.log и standby.log.

Риски и смягчения

Потеря данных при ошибках в командах rsync или ошибочном удалении каталога назначения. Смягчение: иметь свежую резервную копию и тестовый план отката.
Переменные среды и конфигурация на новом хосте (fsync, ownership). Смягчение: проверить права и параметры postgresql.conf перед запуском.

Короткий словарь

PITR — восстановление до точки во времени; позволяет применять WAL-файлы для реконструкции состояния БД.
WAL — Write-Ahead Log; журнал изменений, применяемый при восстановлении.
base backup — базовый снимок каталога данных PostgreSQL.

Заключение

Этот метод позволяет минимизировать время простоя при переносе PostgreSQL 8.3, сочетая создание base backup и применение WAL-файлов на целевом сервере. Он надёжен при корректной подготовке, наличии места для архива и точном следовании шагам. Всегда проверяйте процесс на тестовой среде перед работой в продакшене.

Сводка: Планирование, резервное копирование, настройка архивации, синхронизация данных и аккуратное создание trigger-файла — ключ к успешной миграции с минимальным простоем.